In case you’re a little slow, that last paragraph was filled with between-the-lines complaining about corporate marketing politics, over which I have no control or influence.  I work for ‘the man’ now, so my bark is that of a neutered wiener dog, and I have to opt to say nothing more than I care to admit .  I ask you, “how the hell can a blogger be successful by saying nothing?”  It’s a conundrum.  Suggestions welcomed.  I digress.  Moving right along…

One thing is for sure: customers almost always want more features for less money.  So I’ll make the assumption that now that AP-based spectrum analysis features exist, customers will want it in their system…provided they don’t have to pay extra to get it.  That said, some folks may be willing to pay a tad extra to get it, but my gut says that they aren’t willing to pay much.  Think of it similarly to WIPS, which is a 10/80/10 market.  10% don’t care about security, 80% want whatever is free and “good enough”, and 10% want everything that you can offer them regardless of price.  Spectrum analysis is a lot like that.  With Cisco’s spectrum analysis enabled APs costing an extra $500/AP, even Cisco knows that they can’t pitch it as, “make every AP an spectrum-analysis AP today!”  Instead, they approach it like they would dedicated WIPS sensors – a 1:4 or 1:5 smathering of spectrum-analysis APs as a phase-in approach.

Everyone should realize that spectrum analysis will soon enough, like airtime fairness and integrated rogue detection, be “table stakes” for infrastructure vendors.  The functional differential between each vendor’s spectrum analysis, WIPS, airtime fairness, and a half dozen other major features will shortly be irrelevant.  The technology is maturing just that fast.

I’d love to hear some feedback on how important spectrum analysis is to your deployment (whether it is or it isn’t important) and how you view spectrum analysis as an infrastructure-side technology.

The Micro Branch Office

From a Wi-Fi perspective, this type of office is served with a single AP.  In order to keep costs down in organizations who have hundreds or thousands of branches, vendors who produce gateways that have integrated Wi-Fi are usually considered alongside enterprise-class Wi-Fi vendors.  While there are certainly scenarios where an organization wants to keep Wi-Fi separate from routing/switching/firewalling/gatewaying (I just made that word up), such as when the router/switch/firewall needs to be in one location and the access point needs to be in another location, but if their branch offices are tiny and won’t grow, sometimes throwing it all into one box can make sense financially so long as the necessary feature set is available in the platform.

Enterprise-class Wi-Fi vendors rarely wish to have their APs perform these types of functions, and when they do, they rarely work as well as dedicated gateways designed to do those particular non-WiFi functions.  I’ll give you an example…

Motorola has a reasonably good enterprise-class Wi-Fi solution.  Nothing super fancy.  Nothing revolutionary…but it’s not bad as Wi-Fi solutions go.  I’d certainly choose it over Cisco’s solution.  Anyhow, Motorola’s AP-7131 can be turned into a single-AP branch router.  When I first played with it, I thought, “hmmm…pretty nice…” until I tried to actually get it to work as described.  Anyone dealing with that – you have fun now.  …and don’t call me for support.   Hey, I’m not railing on Motorola actually.  Again, as enterprise-class Wi-Fi solutions go, they have a decent solution, but branch office routing isn’t their area of specialty.  It’s no different with other vendors who are trying to be everything-to-everyone.

The other side of that coin is when the SOHO and SMB vendors try to step up into the enterprise market.  There are quite a few in that market actually: NetGear, SonicWall, WatchGuard, Fortinet, and many more.  They all make decent UTM gear for the SMB and even for branch offices in the enterprise, but their Wi-Fi solutions (for the ones who have them) are weak.  When they move to WPA2-Enterprise with multiple APs, their solutions aren’t really worth discussing.

There’s a bit of a gap at the moment, where the SOHO/SMB vendors are trying to reach upward and the enterprise players are trying to reach downward.  The best technical fit for the customer often depends on how the customer’s network architect likes to build out their networks and what feature sets they are looking for.

The Macro Branch Office

From a Wi-Fi perspective, this type of office is served with multiple APs.  The larger the branch, the more toward enterprise-class Wi-Fi offerings customer usually lean.  There are five workable options for the macro branch:

1) Autonomous APs – many UTM vendors do this

2) Remote APs – which connect to a centralized (e.g. HQ Data Center) controller over a WAN pipe

3) Local controllers at each branch with thin APs

4) Local gateways that act like controllers with thin APs

5) Controller-less APs that coordinate the control plane among themselves

Option 1 sucks.  Don’t do it.
Option 2 is usually no better than option 1, and depending on the vendor, sometimes worse.
Option 3 is very, very expensive, though it will work fine.  Did I mention how expensive this option is?
Option 4 isn’t bad, but it depends on how well the vendor has implemented both sides of the equation (and it’s very rare that a company is good at Wi-Fi and branch office routing/firewalling).
Option 5 yields inexpensive and super-solid Wi-Fi, but doesn’t offer branch office gateway services (though it will offer firewalling and VPN).

I’m starting to wonder when those mega UTM companies that focus on security and infrastructure are going to start finding ways (OEM, acquisition, new product lines, or whatever) to approach the macro branch situation.

Has you installed lots of Branch Office Wi-Fi, faced the micro- versus macro- scenarios, struggled over finding the best solution, and care to comment on your experiences?

Since then…crickets.

* Who currently supports 802.11n TxBF?  There’s nothing on the market yet, but some new Enterprise-class Wi-Fi chipsets now have single-spatial-stream TxBF capability.

* Is there a Wi-Fi Alliance certification for (or that includes) TxBF?  No.

* When will the industry adopt 802.11n TxBF as table stakes?  No idea.  No announcements by anyone.

For 802.11n TxBF, the time of going from “No idea when” to “Table stakes” could be measured in years…or perhaps never.  Let me explain why.

Step 1:

Enterprise Wi-Fi chipset vendors like Marvell, Atheros, Broadcom, and others have to build it into their chipsets and then supply the chips and code to the AP and Client vendors.  This is happening, but only for single spatial stream transmissions at this time.

Step 2:

Enterprise equipment manufacturers like Aerohive, Aruba, Cisco, Motorola, and others have to integrate these chipset and their code into our platforms.  This goes for both infrastructure and client vendors.  This requires a new spin of hardware, which ain’t quick.

Step 3:

The Wi-Fi Alliance has to decide to put TxBF functionality into one of its Wi-Fi certifications, and perform plugfests that include it.  5 AP and 5 client vendors must participate in the process or there will be no certification.  There’s actually alot more to this step, but I’m trying to keep this brief.

Even if we get through all of these steps, we’ll still only have TxBF support for a single spatial stream (up to 72 Mbps) due to how 802.11n TxBF works.  It takes at least two radio chains to do beamforming, and so whether you have 2 or 3 radio chains, you’re only going to be transmitting one spatial stream.  Additionally, 802.11n TxBF is only good for medium range.  At close range, you don’t need beamforming because the client and the AP can hear each other perfectly well.  At longer distances there are too many reflections within the environment for the transmitter (Tx) and receiver (Rx) to characterize the channel well enough to do TxBF with any accuracy.

There is one cool thing that we can do with TxBF that’s useful in the interim though, and that is extending the distance of mesh links some.  Since interoperability with yourself isn’t too much of a problem, some vendors may choose to support TxBF on mesh backhaul links for the purpose of extending the range of such links by some modest amount…and modest is yet to be defined.

So the summary is:

It’s going to be a long while before TxBF will be used (due to client support, Wi-Fi Alliance certification, etc), and even then, it will be useful for medium range, indoors, with a single spatial stream.

Anyone care to chime in?

1) Compatibility with iEverythings
2) Tools for the reluctant administrator (aka the network operator)
3) Ease of management

Compatibility with iEverythings

In K-12 WLANs, diversity of the client population depends on school policy.  If the school issues client devices to students, that certainly makes things a little easier from a compatibility standpoint, but it’s an expensive proposition.  If you took only a single client device vendor as an example (let’s say Apple), then you’d have to consider iPhones, iPods, iPads, MacBooks, MacBook Pros, MacBook Airs, iMacs, Mac Minis, and Mac Pros.  Good grief.  Unfortunately, I’m not exaggerating here.  ALL of those, plus hardware, operating system, and driver variations on many of them could be connecting to the network all at the same time.  The compatibility testing for just Apple client devices could take forever.

What if we dove into HP, Lenovo, Toshiba, Blackberry, Motorola, and all the rest?  The combinations are staggering.  While the Wi-Fi Alliance certifications are designed to test basic compatibility, they aren’t comprehensive enough to help vendors avoid all compatibility problems.

Rather than tell you what I think we should do, I would like to hear from you.  What do you think vendors should do?  You’re on the front lines.  You see it every day.   You experience the pain of this problem.  We’re all ears.

Tools for the reluctant administrator

The teacher calls down to the Tech Support department and says, “Bob, I have 3 students who can’t connect…again.  Can you fix it?  I really need to get this lesson completed today, and it requires that the student visit a particular website.”  Bob laughs out loud, says that “he’ll take a look at it”, and an hour later, after asking the teacher for Mac addresses, student names, and having to walk down to the classroom to verify the symptoms, Bob finally fixes the problem….just in time for the bell to ring.  The teacher isn’t exactly happy, and the principal wonders why she isn’t getting her job done.

Enter TeacherView.  Check out my blog on it here:  http://blog.aerohive.com/blog/?p=326

Basically, TeacherView is an application that runs on the Wi-Fi infrastructure that allows a non-technical network operator, like a Teacher, to get their job done without having to understand the nuances of Wi-Fi infrastructure.  It shows each student’s connectivity status and can help the teacher maintain control of each student’s Wi-Fi and website connectivity.  It’s like giving the teacher a little IT buddy.

Are there other such tools for WLANs in K-12 that you can think of that would help solve operational problems like this?  If so, please throw them out there, and we’ll certainly take a look!  It doesn’t have to be an application.  It can be anything.  Again, we’re all ears.

Ease of Management

Sam:  “Hey Bob, can you tell me how to configure an SSID with just guest Internet access and 512 Kbps of bi-directional bandwidth?”

Bob:  “Uh, no.  I haven’t been through the class.”

Sam:  “Dude, why did we buy this stuff if it’s this hard to use?”

Bob:  “I like orange.  ….no wait, the dog ate my homework…yeah, that’s it.”

You may think this is way off-base…but it isn’t. 

The problem comes in when trying to build a GUI for the mid-market and for the large enterprise.  Large enterprise needs a large feature set to tackle a large variety of issues.  Mid-market typically needs a modest feature set.  K-12 WLANs often live right between the two, though they can skew to either side with the size of the school system.  There are a variety of ways usability can be addressed, such as:

* Having 2 GUI interfaces, one for each market
* Hide complex features until they are needed
* Expect admins to just learn the enterprise GUI and feature set

Which do you think Wi-Fi infrastructure manufacturers should do as a general rule?  Is there a 4th option?  Do you hate your GUI?  I’d love to hear some feedback on usability, GUI, and even deployability.  Whatever would make your life easier.

WLANs in K-12 can be a tricky beast, and the more the manufacturer knows about the problems you face, the better we can help you address your issues.  We’re ready.  Fire away!

Blogs get boring without pictures, so I’m including one just to make the blog look better.  Once you look at it, ask yourself if you feel better about this blog just because there was a picture.

This blog is going to make some statements and pose some questions about three topics that are related to WLANs in K-12.  We’d love to hear some informed and first-hand answers from the audience (especially those who operate or install WLANs in K-12) on answers to the questions, opinions, problems, concerns, and more.  Think of this blog as somewhat of a poll mixed with a discussion.

TOPIC #1

Let’s start by discussing the good folks who operate WLANs in K-12.  Since K-12 organizations run the gamut in size and wealth, the training and experience of the network managers/administrators vary widely as well.  Some rely heavily on their providers (whether it’s the manufacturer or the Value Added Reseller (VAR)) to recommend the right solution and then to design, install, and test it.  At the other end of the spectrum, some administrators in K-12 have years of experience in IT and have taking a liking to Wi-Fi over the last several years, which has yielded them some deep and useful experience.

Question:

With that broad of a range of knowledge and experience, should Wi-Fi infrastructure manufacturers be designing their platforms for the least common denominator, for the most sophisticated user, somewhere between the two, or a full combination of both?

Some aspects to keep in mind while answering this question are:

* Graphical User Interface (GUI)
* Architecture & design simplicity
* Deployment flexibility & simplicity
* Troubleshooting simplicity

TOPIC #2

Let’s discuss the kind of user density that WLANs in K-12 have to cope with.  The rule-of-thumb is one AP for every two classrooms, though there are occasions when the customer might desire one AP per classroom for reasons like higher performance and longevity of the Wi-Fi installation.  There are usually around 30 students in a classroom – sometimes a few more or a few less, but generally-speaking, 30 is a good number.  That means that APs need to support, on average, 60 connections.  Those connections could be all data, all video, or perhaps a combination of the two.  Additionally, those same APs have to handle staff (teachers, administrators, etc.) and guest connections, which could be voice, video, and/or data.  The worst-case scenario may be as high as 100 connections per AP, and handling the “triple play” for 100 simultaneous users on an AP isn’t for the faint of heart.  There are many parts and pieces to handling that kind of client density with mixed PHYs (802.11a/b/g/n): Airtime fairness (uplink and downlink), uplink/downlink flow balancing, bandsteering, load balancing, minimizing roaming, thinning out unnecessary control frames, affecting granular QoS per-application/per-station, and oodles more.

Many Wi-Fi infrastructures fail miserably under those conditions, even though their spec sheets say otherwise.

Questions:

How much testing is actually done to prove that these features (if the vendor claims to have them) work before a purchase is made?  How much does that depend on the experience & training of the network administrator or their trusted MFR or VAR?

Some aspects to keep in mind while answering these questions are:

* Many network administrators are over-worked because the school is under-staffed
* Time is money, and spending alot of time on testing might sometimes seem wasteful
* Many network administrators don’t have the know-how, software, or hardware to test complex features

TOPIC #3

The last topic is about integration with backend systems (Ethernet switches, authentication systems, remote access, etc.).  This is a monstrous topic rolled in a tiny summary.  There are two sides to this fence.  First, many of these technologies are mature and well-known, though their implementations can sometimes be overwhelming.  Second, for large school systems, backend systems can still be very complex and extremely diverse with so many competitors and everyone doing things slightly different.  I have definitely seen some K-12 administrators who make the impossible look simple, but I’ve also seen some who couldn’t administer an unmanaged, SOHO Ethernet switch (kind of like that guy who was trying to change modes on our ISC).  802.1X/EAP with RADIUS and Directory Services is the most common stumbling block we see as K-12 (in general) moves toward using enterprise-class Wi-Fi infrastructure instead of SOHO equipment, but there are certainly others.

Question:

What are some technical advancements that you’d like to see that would ease administrators’ pain with integrating with backend systems?

Some aspects to keep in mind while answering these questions are:

* Other than connectivity into the Ethernet and 802.1X/EAP authentication, what are other pain points?
* Many new advancements are being made on the RF and 802.11 protocol fronts that make applications work better.
* Infrastructure-aware applications that address non-technical operators, rather than just administrators, are now available.
* There are various architectures available now (In-the-LAN controllers, cloud-based controllers, & controller-less) to choose from, and each integrates differently)

Again, this is just a discussion/poll to get some valuable feedback from the audience of this blog.  This feedback will help us understand what problems you’re experiencing, what ideas you have, and how to build more applicable products.

Thanks for your participation!

You want to connect wireless clients on both 2.4 and 5 GHz simultaneously?

Piece of cake.  There’s a role for that.

You want to connect a remote AP to the HQ network via VPN while providing wireless access and split tunneling?

There’s a role for that.

You want to connect some wired devices to the wireless network via mesh backhaul while still serving wireless clients off of the same AP?

Yes, there’s even a role for that.

There’s a role for almost everything now. If you can dream it up, at least one AP vendor will make it for you.  Why else would vendors put VPN servers and clients in APs?   What bugs me is when a role is made into a mode, and the mode limits functionality.  What I mean is that many vendors will give you a selection of operating MODES, and when the AP is put into one of those modes, many of the features of the other modes are now missing.  You read things like, “In Mode-X, you get blah, blah, and blah features but you don’t get blah, blah, and blah features.”  Sometimes a vendor might have 5-6 operating modes, and each will have some things and will be missing some things.  Then, over the course of many revs of code, they add features from one mode to another mode…all while creating new modes that have very little.  Basically these modes pigeon hole the user, forcing them to make a choice on what they must give up to get what they have to have.

Shouldn’t you be able to define a role for the AP and not lose any functionality?  Basically what I’m saying is that I want all of my features, all of the time.  I paid for those features, and I want to use them whenever I feel like it.

I’ll give you a couple of real-world examples of feature loss from our competitors’ playbooks:

*  You can have distributed forwarding, but if you try to do it with more than 32 APs, you lose your stateful firewall filtering.

*  You can have remote AP functionality, but not with fast/secure roaming between APs.

So, I’m all for the AP playing lots of roles, as that provides deployment flexibility.  I’m not for locking those roles into feature-limited and functionality-constrained operational modes.  That’s sucky.

Now that the acute pain has subsided from the fruit-basket-turnover that was switching from a Blackberry to an iPhone4, I’ve begun the long march toward switching from a PC to a MacBook Pro (MBP).  My kids are now on iPhones, I’m begging my wife to switch to an iPhone (she’s as much of a Blackberry hound as I’ve been for about 12 years), I have an iPad, I load iTunes on everything, and I carry around an AirPort Express everywhere.  I just snagged a MBP, and my friend Keith convinced me (and rightly so) to use Me.com for synchronizing calendaring, contacts, iDisk, and the rest.  I’m almost there…close enough to feel it!

With the MBP, I have to learn the OS, find and learn the apps, wait on Microsoft to come out with Office 2011 (because my OCD issue won’t let me use something that’s just about to be obsolete like Office 2008), wait for about a half dozen other vendors to finalize their betas of my favorite apps (e.g. SnagIt, UltraEdit, and a few more), and then all of the rest of the things you have to do to make the switch (like figuring out how to map drives, add/remove apps, do automated backups, getting all of your Windows-only apps (NetStress, The Bat!, NitroPDF, etc.) running on Win7 inside Parallels, and all of that crap).  Even after you “switch”, you really haven’t switched due to some of your beloved apps being Windoze-only.  Thank goodness for Parallels.

I will make the official and full switchover sometime in October.  Microsoft will decide when.  Right now, I’m mid-stroke between my beloved Lenovo and my crazy-cool MBP, and being mildy OCD (such that everything is black/white in my world), I’m struggling emotionally.  The only thing that’s supposed to be mix-n-match is a set of golf clubs, and outside of that, I’m a purist.

Something I’m interested to see is the Wi-Fi compatibility and speed of all of these iEverythings.  I’ve found some OSX apps that give you a little throughput information, but nothing fancy…I mean, one of them is $16, so what do you expect?  I’d love to see some Wi-Fi protocol analyzers made natively for OSX.  Wireshark requires a bunch of fancy hacking to get it running, and even then it’s missing important features.  Fluke/AirMagnet Wi-Fi Analyzer Pro, Tamosoft CommView for Wi-Fi, and Wildpackets OmniPeek don’t have an OSX version.  Oy.  Where’s the love?  Don’t they know that Apple is now bigger than Microsoft and has $46B in the bank?  Somebody even needs to make a protocol analyzer, site survey tool, and spectrum analysis tool for OSX and iPad OS already! 

Over the last few years, iPhone apps have been plenty, but OSX apps have been few.  Surely I’m not the only person on the planet going through this process, so hopefully there will be lots more OSX apps soon.  To be honest, I’m mostly concerned with diagnostic and Wi-Fi networking related apps.  That’s my little world, and there’s just not much to be had in the way of Apple apps.

Anybody want to share their experience, some things they’ve discovered going through this process, or some cool apps that would help me out?

If you really want to help a brother out, tell your favorite app vendors to make an OSX and/or iPad version of whatever cool apps they make.  Jobs and company is here to stay and there’s gold in them there apps.

Suppose for a moment that your organization has 100 locations, each with 6 APs.  We call this a macro-branch (as opposed to a micro-branch, which only has 1 AP).  In a macro-branch scenario, you have four options:

1) 6 Intelligent APs (Controller-less)
2) 1 or 2 small controller(s) with 6 APs (depending on the redundancy requirements
3) 6 Hybrid APs (e.g. Cisco H-REAP, Aruba’s Remote AP, etc)
4) 6 Autonomous APs

#4 is out because it’s…well…so 2002-ish.  Only people with “extra money” do  #2, and I don’t know anyone with extra money, so #2 is typically eliminated from consideration early on in a deal this size.  That leaves #1 and #3 to duke it out.

Besides all of the obvious stuff (like APs in #3 don’t share information and lose 50-100% of their functionality as an AP), there’s this “other” thing I wanted to talk about: distributed software download.

Most organizations with that many locations don’t have 100 Mbps pipes to each location, rather it’s usually inexpensive ADSL, T1, or similar pipes.  Downloading firmware to each AP individually, when firmware images for APs range from 20-50 MB (depending on vendor) seems problematic.  Aerohive images range around 30 MB, and doing the math, that would be 180 MB per site.  Aerohive’s Distributed Software Download feature can now have the management platform push a firmware image to one AP in the Hive, and that AP will distribute the firmware to other APs over LAN links (100/1000 Mbps Ethernet, 300 Mbps mesh, etc).

No more busy WAN pipes for distributed enterprises.  Sweet, eh?

It’s the power of distributed processing.  Get used to it.  It’s the future.

Like John Gage said, “The Network is the Computer.”  Oh, did I mention that John Gage works for Kleiner Perkins, one of our esteemed VCs?

As a matter of fact, so does Vice President Al Gore, who has actually lent Aerohive a helping hand in the past.  How cool is that?

Meanwhile, back at the ranch…  We join a Coordinated AP (C-AP) family in the middle of their evening meal…

C-AP-1: You see C-AP-2, when Client-7 arrived at my house this morning, I had already been notified by Headquarters (HQ) that it was coming to my house, and that when it arrived, I was supposed to have specific Internet and phone restrictions in place for it already.

C-AP-2: I see what you’re saying C-AP-1, but does HQ always notify us ahead of time about all of these restrictions when a new Client comes to town?

C-AP-1: Yes, and since there could be lots of different User Profiles defined by HQ, someone from HQ will have to call and tell you which profile to use for the new Client.

C-AP-2: I see!  That’s easy enough.  So what about when the Client moves between houses?

C-AP-1: As soon as the Client arrives at your house, drop me and everyone else who lives right around you a quick email letting us know that the client is there, and give us it’s User Profile information.  We’ll all be ready for it if it decides to swing by any of our houses.  We’ll then do the same if it comes by our house.

—————–

I’d like to introduce you to the Coordinated AP (C-AP).  There are actually two kinds of C-APs: controller-based and controller-less.  The control-plane, whether implemented in software and hardware, or just software only, is the set of functions that allow APs to communicate and coordinate among themselves.

The point of this blog isn’t to rail on controllers (though I’m happy to do that pretty much all the time), but rather to clearly explain the difference between autonomous and coordinated APs.  Autonomous APs don’t talk to each other.  Controller-based Coordinated APs share information with the controller, which in turn shares it with other APs.  Controller-less Coordinated APs share information directly with each other.  Hardware controllers and control protocol suites both get the job done, but there are clear advantages in many scenarios to operating the control plane with protocols rather than hardware/software.  That’s a long-winded discussion for another day.

—————–

The Motivation:

I’ve found it very disturbing that Cisco, Aruba, and Meru have all recently told potential customers for whom we were competing, that Aerohive sells autonomous APs.  Nothing could be a bigger fabrication and further from the truth.  They are grasping at anything that would allow them to be more competitive, and in this case, they’re just being dishonest.  You might think, “perhaps they don’t understand your technology well enough to articulate it”, but that’s absolutely not the case.  Each of these vendors understand our technology well enough to know that what they do in hardware and software, we do in inter-AP protocols.  They understand what we do well enough, in fact, to be putting major resources into replicating what we do.  Aerohive’s control plane is far more robust than theirs (no single points of failure, no bottlenecks, lower cost, etc), and therefore they are banking on, and preying on, the ignorance of the customer base in order to be competitive against Aerohive while they attempt to build what we already have.  Then suddenly, they’ll act as though it’s always been their plan and that they are the only company in the world who knows anything about controller-less technology.

This kind of repugnant spin says that they care more about making money than solving customer problems, being honest with and building a relationship with their customers, and maintaining their integrity.  Lest you think I’m making this stuff up, I have the competitive vendor documentation in my possession to prove it.  It’s a seriously sad state of affairs, no?  At Aerohive, we take a different approach (as usual).  Competitors have what they have, and they do what they do.  Our job is to offer the customer something that better solves their problems, regardless of what our competitors have or do.

If you hear “Aerohive” and “Autonomous APs” in the same sentence from a competitor, yea in the same paragraph, push back.  It’s spin.  Here is a step-by-step progression over AP types over the last 10 years:

1)    Autonomous – Standalone APs, managed individually

2)    Autonomous – Standalone APs, managed with a Wireless Network Management System (WNMS)

3)    Controller-based – Dependent APs, coordinated and managed by a single controller

4)    Controller-based – Dependent APs, coordinated by one or more controllers, which are managed by WNMS

5)    Controller-based – Dependent APs, coordinated by a group of controllers, managed by WNMS, that are adapted to help transition the WLAN to high-throughput, mission-critical support

6)    Controller-less – Intelligent APs, managed by WNMS, that use inter-AP protocols to coordinate all control tasks for high throughput, deployment flexibility, and mission-critical support

One vendor in particular, who, for now, will remain nameless, has even said that our APs are 2nd generation, while there controller is 4th generation.  Where in the hell do they come up with this stuff?  I’ll bet this vendor skips 5th and 6th generation and goes straight for 7th generation in their next product line. Oy vey.

The truth of the matter is that most (at least the smart ones) of Aerohive’s competitors are moving from step-5 above to step-6 above as we speak.  It simply has to happen.  There’s just too many compelling reasons why controller-less is the next generation of Wi-Fi to deny it.

In golf, “greenies” are awarded to the player who hits the green in regulation and is closest to the hole.  Some play a variation where the greenie is lost if the player three putts.  In that case, the greenie is awarded to the player second closest to the hole.

While thinking about greenies, I got to thinking about how “green” Aerohive’s solution is.  Hey, what can I say?  My mind wanders all over the place.

Enterprise-class Wi-Fi solutions consist of 3 de facto standard components:

1) APs
2) Management System
3) Controller(s)

By replacing hardware controllers with protocols that operate within and between APs, all controller hardware can be replaced.  That includes

1) giant controllers that live in the data center (and their redundant counterparts)
2) branch controllers (that live at each branch, along with their redundant counterparts)
3) edge controllers (that live in the wiring closet)

Just by removing controllers, you have removed:

1) The electric power, fuel, and waste that it takes to manufacturer and ship controller(s) to customers
2) The data center, wiring closet, or branch office electric power and cooling it takes to operate the controller(s)
3) The landfill space that controllers take up at their end-of-life

Some vendors talk about “virtual” controllers in order to tout a “green” story, but the truth is that their controller software (which usually operates within a VM) has to run on some kind of hardware.  Whether it’s an appliance or a big array of servers, it’s still hardware…and it’s still un-green.

Aerohive undoutedly gets the “Wi-Fi Greenie” because no other vendor in the Wi-Fi market has been able to eliminate the hardware associated with one of the three de facto standard components of a Wi-Fi solution.  Additionally, by making our management system, called HiveManager, virtualizable, a single piece of hardware can operate several dozen instances of HiveManager…instead of only one instance like most of our competitors.  If you don’t want yet another management platform in your data center, you can opt for HiveManager Online (HMOL) – Aerohive’s Cloud-based, fully-redundant wireless management system.  With HMOL, your power and cooling bill are further reduced…along with your capital expenditures on network management.

I think it’s only a matter of time before other vendors will get tired of longer putts for birdie and will copy what Aerohive is doing.

Did you notice Aerohive’s launch of TeacherView?  Applications that use the wireless infrastructure as their hardware is a whole new kind of green.  The “TeacherView Server” is actually just an app running on HiveManager that allows for initial Teacher authentication.  Thereafter, the APs take over and run everything.  New apps, but no new hardware.  Sun Microsystems had it right: The Network is the Computer.   It’s yet another way that Aerohive is keeping our platform green without you spending alot of green.