Archive

Archive for the ‘WLAN planning’ Category

Management System Diversity: “Manage WLANs from Anywhere Using Anything!”

April 2nd, 2014

So much competitive marketing noise has been made over the last half dozen years about managing WLANs that vendors are now trying to manage WLANs from anywhere using everything. It wouldn’t surprise me in the least to hear a vendor say that they can now manage a branch WLAN in France from the comfort of their kitchen’s refrigerator’s management widget. It has gotten downright silly. I thought I would recap just how diverse the WLAN management scene has become: first for a good laugh, and second as a reference for those newcomers to the Wi-Fi industry.

You may be thinking, “why are there so many ways to manage a Wi-Fi system?” There’s a variety of answers to that question, such as:

  • Cost
  • Differing use cases
  • Partner eco-system
  • User preference

Not every vendor provides each of the management methods described below, but rest assured that every vendor will tell you that you don’t need anything other than what they sell. Can I get an amen? Below, I have offered a visual reference of the seven prevalent methods of managing a Wi-Fi infrastructure. It’s important to note that I will not address Wi-Fi client management methodologies in this post.

WLAN-management-diversity

WNMS in a Virtual Machine (VM)

One of the most popular methods of deploying a true WNMS today is as a VM. It’s a low-cost, flexible, scalable option that is profitable, easily updated, and easily distributed for vendors (since it’s only software). Customers love it because almost every organization has a VM infrastructure these days. Those who don’t typically use…you guessed it…the cloud. VM-based WNMS systems are classified as true WNMS because they can manage multiple elements across multiple locations, they usually handle policy-based management, compliance/reporting, location services, configuration/monitoring, planning, and much more.

WNMS in an Appliance

A WNMS in an Appliance is simply WNMS software that has been installed onto an appropriately-chosen hardware platform by the vendor. A set of recommended specifications are then documented by the vendor that informs user about the maximum number of devices that should/can be managed with the platform. Sometimes the vendor security-hardens the platform as a value-add.

Wireless Network Management System (WNMS) in the Cloud

Cloud management is all the rage. In fact, if you’re a vendor and don’t offer it, I dare say that you’ve fallen dreadfully behind the times. Cloud management is especially appropriate for users with distributed environments, remote or home-based workers, and those who prefer an OPEX-based (subscription-based) payment strategy.

Do not confuse putting a hardware or software controller (or set of controllers) in a data center for cloud management. A cloud management system is a multi-tenant system whereby system resources can be allocated and provisioned to various customers leveraging economies of scale. A cloud system is flexible enough to grow when/where needed and is essentially unlimited in scale. Vendor marketing departments love to cause confusion around cloud offerings when their company does not offer cloud management as an option, so be sure to ask your vendor to explain what their cloud is and how it works.

The term Public Cloud means pretty much the same thing across all vendors who use the term, but the term Private Cloud has varying meanings across vendors. It’s for that reason that I wanted to clarify the two prevailing definitions for Private Cloud:

  • Definition #1: WNMS (Appliance or VM) in a private data center
  • Definition #2: Dedicated (versus the normal shared) server space within a cloud infrastructure

Customers should ask their vendors to clarify what they mean when they use the term Private Cloud.

Application-based Management

Some vendors have chosen to put their configuration interface into an application, and these applications are now beginning to show up on mobile platforms (e.g. iPad). Application-based management software for mobile platforms is often a subset of the desktop version or controller-based management interface and is meant to offer the user an exceptionally good experience. Mobile applications are renowned for their simplicity, beauty, and flexibility. These applications are heavily focused on configuration, and are likely to have very little in the way of monitoring, reporting, location services, planning, etc.

Such management applications tend to be element managers rather than policy-based management systems, and are often not sophisticated. Their benefit lies in their simplicity and flexibility.

Controller-based Management

The reason that I don’t give controller-based management the moniker of WNMS is that controllers were never designed for full-scale management. You can think of the CLI or GUI within a controller as being designed in the original likeness of an autonomous AP. Autonomous APs had (and still have) an integrated GUI (and some had a CLI) designed primarily for configuration. While configuration is part of management, autonomous AP GUIs/CLIs had few monitoring, reporting, planning, mapping, or other management functions within the interface. Likewise, when the industry moved to controllers and controller-based APs, the controller became the original point of configuration.

While a reasonable amount of monitoring sophistication has been added to controllers over the years, controller-based management is still element-based (meaning that it only monitors itself) and contains almost none of the common enterprise-class, large-scale WNMS features.

Controller-in-Software Management

Yes, vendors actually do this. The make a software controller and run it as an application or within a VM. Either way, it acts exactly like a controller appliance and has all of the management shortcomings thereof. However, it may be offered to customers at no charge, which is a strong benefit. You still have to consider the cost of the hardware that the software must be installed onto, but that could well be a sunk cost already or minimal because it’s a set of shared commodity hardware within your data center. A saving grace of this approach is that with it being a pure software play, it’s possible for such platforms to morph more quickly into a true WNMS.

Master Access Point (AP) based Management

We have seen systems come and go over the years that sported this feature. Some vendors have installed the feature and then taken it back out again because they felt like it took away from their ability to sell other types of management (e.g. cloud). Managing a set of APs via a single Master AP can be very simple, free, and yet is always scale-limited by design. Depending on the vendor, this choice can be feature-rich or feature-poor, but it’s often great for small mid-market customers who have a single location or have a qualified administrator at each location.

Like Controller-based Management, the interface found in Master APs is usually highly geared toward configuration. There may be some modest amount of monitoring capability, but it’s not comparable to a WNMS. Further, other WNMS important features such as reporting, location services, and planning are missing. It’s for these reasons that I do not call this form of management a WNMS.

Summary

There are just so many….take your pick(s). Some are free. Some are crazy-expensive. Some are CAPEX-based, and some are OPEX-based. Most vendors offer at least two methods of managing their Wi-Fi infrastructure, and some vendors purposefully don’t offer specific types of management interfaces out of fear that it will cannibalize certain others that they sell. Some vendors go all-out and provide everything with the hope that their flexibility will win out in the end. There’s probably no best approach, so you should decide for yourself.

When you get into today’s frequently-overheard conversation about unified wired/wireless management (among the large campus enterprise vendors) the proper choice of WNMS becomes even more important. Should you go with a single-vendor or multi-vendor system? Some vendors have used multi-vendor WNMSs to woo customers away from their competitors over the years, and the strategy has worked remarkably well in some cases.

I could go on and on about management systems, but I think that gives you a good primer. What are your thoughts? Want to share any insights?

Best practices, Cloud computing, WiFi Access, WLAN planning

Away from Corner Cases: High Density, Low Throughput Wi-Fi

March 19th, 2014

In my blog called Corner Cases, I mentioned that high density, high throughput (HDHT) cases are in the extreme minority (<1%). In this blog, I would like to discuss High Density, Low Throughput (HDLT), which I believe will be the situation that over half of the installed Wi-Fi infrastructures of the world will face at some point over the next 5-7 years. I want to clarify that that when I use the term “high density”, I’m referring to client density (lots of clients in a physical area), not AP density (lots of APs in a physical area).

Unless you’ve been camping out under a rock, you may have heard the term “Internet of Things” or IoT for short. This moniker refers to the movement toward connecting previously-unconnected devices onto the Internet. To clarify, things are being connected to the Internet, thus we get Internet of Things. So how many of these things are we talking about? Oh… a few I suppose. Gartner is saying there will be 26 billion IoT devices and an additional 7.3 billion smartphones/tablets/PCs by 2020. The vast majority of these devices will connect wirelessly, so we’re about to see a crazy explosion in device density. Obviously it doesn’t all grind to a stop in the year 2020, which is truly just around the corner.

The important point to make here is how device density affects: 1) network design, and 2) the type of equipment you purchase to appropriately support your customers (over the lifecycle of your next infrastructure upgrade/refresh). Most vendor marketing departments like to tightly bind high-density and high-throughput requirements together, but they are completely separate topics. You can have the following scenarios:

  • Low Density, Low Throughput (LDLT)
  • Low Density, High Throughput (LDHT)
  • High Density, Low Throughput (HDLT)
  • High Density, High Throughput (HDHT)

HDLT: the de facto standard

I don’t think that comes as a surprise to anyone. In the Corner Cases blog, I specifically addressed HDHT networks and pointed out that they are in the extreme minority today. HDLT networks are reasonably common today, but usually not to any extreme. When IoT bears its full weight on the market (which will be far sooner than you might realize), HDLT networks will be the de facto standard. In a nutshell, this means that APs will need to associate (connect) lots of devices (I foresee 100+ devices per radio becoming common fairly soon), but the traffic to/from each of those connected devices may often be sparse. APs will likely need good QoS, a good understanding of client behavior and needs, and of course security will be all-the-more important with the breadth of devices connecting to the network.

Let’s consider a specific scenario, the average branch office (perhaps real estate or insurance) with 20 employees, to make my point. Today, the branch could possibly have the following devices connected to the Wi-Fi infrastructure:

  • Laptops
  • Tablets
  • Smartphones
  • Printers (let’s hope not, but you never know)

Let’s fast-forward to the year 2020 and consider how that same branch office might look from a technology standpoint. What items within the office could feasibly be Internet-connected in addition to what they have today?

  • Security cameras
  • Printers (they definitely will)
  • Digital signage
  • Digital picture frames at workers’ desks
  • Appliances (e.g. refrigerator, water cooler, coffee maker)
  • Cars that are within range of the in-building (or outdoor) Wi-Fi
  • Wearable technology (watch computers, eyeglass computers, etc.)
  • Building controls (thermostats, security systems, fire systems, etc.)

I’m sure I could go on and on, but for the sake of time, I’ll stop listing things. I’m sure you got my point. It’ll be a ton of things for sure. Some will want some bandwidth (e.g. picture frames sucking down 3MB photos from a file share on a server at a pace of 1 new photo every 5 minutes times 10 picture frames in the office), and some will want very little (e.g. your digital watch updating you on the temperature outside). All-in-all, the bandwidth requirements will be modest at best, but the number of devices will be ridiculous.

Remember how BYOD started? Companies tried to stop it by creating company policies. Yeah, that worked out… NOT. It will be the same way for IoT. It will progress like this:

Users: We want our things on the Wi-Fi.
Admin: No.
Users: Yes, because if you don’t, _________.
Admin: OK, you win, but your devices will be firewalled, rate-limited, and highly controlled.
Users: I don’t care so long as they work properly. Hey wait, why doesn’t my picture frame work properly. It probably needs more bandwidth. Fix it.
Admin: No.
Users: We’ll tell.
Admin: Ugh! OK, it’s fixed, now leave me alone.

BYOD stands for Bring Your Own Device, and trust me, they will, but not just smartphones, tablets, and laptops. They’re going to bring Internet-enabled pens, shoes, and heart monitors. You, Mr. Admin, will be powerless to stop it. You thought all of this BYOD stuff had just about fizzled and was limited to just a few vertical markets didn’t you? Ha. It’s barely even begun, and you haven’t seen complexity yet… just wait. How will you manage those Internet-enabled pens again? No, I don’t mean just at Layer-2… that’s the first step. I mean at Layer-7 also. Sorry I had to break that news to you. Bumpy ride ahead.

There are companies today who are building cloud infrastructures that are specifically designed to manage all kinds of IoT devices for the manufacturers who make them. That’s good thinking. Not every company in the world wants to build a cloud to keep their Internet-enabled devices up-to-date and to push content to them.

In closing, I will reiterate that it will soon be the number of devices, not high throughput, that will become the more significant issue across a large section of the Wi-Fi market as a whole. Make a note, it’s coming.

BYOD, mobile device management, smartphones, WiFi Access, WLAN planning

Corner Cases

February 26th, 2014

Most Wi-Fi manufacturer’s marketing departments would have you believe that 99% of all deployments are what I’d call “corner cases.” I call B.S. (as usual).

Here are the high-density/high-throughput (HDHT) corner cases that so many manufacturers would have you believe are so prevalent:

  • Large K-12 and University libraries, cafeterias, lecture halls, and auditoriums
  • Stadium or gymnasium bowls
  • Large entertainment venues (e.g. music and theater halls, night clubs)
  • Trade shows
  • Urban hotspots
  • Airports

Combined, these use cases comprise less than 1% of all Wi-Fi installations.  In other words, the opposite of what many marketing departments would have you believe. Let’s look at this from another angle. Here’s a list of use cases that do NOT fall into the category of HDHT, but may have other technical challenges or requirements, yet these same marketing departments want customers to believe they are HDHT environments.

  • K-12 classrooms*
  • Malls
  • Majority of airports

* Note: Some folks believe that one AP per classroom (or even one AP per two classrooms) is a bad idea due to adjacent channel interference (ACI) or co-channel interference (CCI), but that’s a design matter based on a long list of design criteria that can include wall construction materials, AP output power, client device type, client device output power, and MUCH more. I assert that one AP per one (or two) classrooms is a good network design in many K-12 environments, and this usually means less than 35 devices per classroom, worst case. 35-70 devices per AP (2 radios) does not constitute high-density, but may necessitate good L1, L2 QoS, and L7 handling.

Consider all of the common deployments that constitute the majority of WLAN environments:

  • Office environments
  • Warehouses
  • Manufacturing
  • Hospitals
  • Distributed healthcare facilities
  • Cafes
  • Bookstores
  • Hotels

So if HDHT handling isn’t a big deal in 99% of the use cases, what is important? If you ask that question to those same vendor’s marketing departments, they would say Performance! Once again, I call B.S.

After speaking with a variety of network administrators and managers, I’ve found it very difficult to find anyone who can produce statistics showing an AP sustaining more than 10Mbps over the course of an 8-hour business day. Even the peak throughput on the busiest APs aren’t all that high (a couple of hundred Mbps sustained only for a couple of minutes while large files are being transferred). It’s been my experience that busy branch offices, with a single AP serving 50-60 people, is where you find the most sustained WLAN traffic over a single AP.

If 10Mbps is considered “a very busy AP”, and decent 2×2:2 802.11n APs can sustain 200+Mbps of throughput across two radios given the right RF and client environment, then why is everyone talking about performance? I hear vendors bragging about their 3×3:3 11ac APs being capable of 900+Mbps of throughput under optimal conditions. While that kind of throughput is sexy to IT geeks who think that “too much is never enough”, most customers just want it to work. At 200-400 Mbps of throughput for 802.11n APs, why do we care so much about buying premium-priced 11ac APs again?

What do we get out of those 11ac APs anyway? 256QAM is useful only at short range and only for 11ac clients. TxBF is only good at mid-range, and only for thoses client that support it, which is basically none. Rate-over-range is better for uplink transmissions, but if you’re designing for capacity, voice, or RTLS, then this is of no consequence. There may be slightly fewer retransmissions due to better radio quality, but that’s mostly “who cares” also. Bottom line: don’t upgrade your 11n infrastructure for the purpose of speed. If speed (e.g. rate-over-range and raw throughput) is your goal, spend your budget on refreshing your 11ac clients first.

Customers who rush out to buy the latest, greatest, fastest AP end up paying a big price premium for a performance gain that they’ll never, ever, ever, ever use. It’s just silly. They get duped by the marketing message that HDHT handling and ultra high-performance matter in 99% of use cases, when in fact it matters in <1% of the real world use cases. Wi-Fi infrastructure technology is progressing quickly, and the PHY/MAC layers are so far ahead of typical use cases that customers should be focused on correct Layer-2 design and receiving value above Layer-2:

  • Robust, global, cloud management and services option
  • Strong security, compliance and reporting
  • Device tracking / location services
  • Social media integration (i.e. Facebook, LinkedIn, Twitter)
  • Guest and retail analytics
  • Managed services enablement

If you’re going to buy (or upgrade to) an 11ac infrastructure, there’s a very important reason to do it that is unrelated to the speed at which you move frames across the air: intelligence. Some APs don’t have the horsepower to do any significant local processing, and that leaves three options related to infrastructure intelligence:

1) don’t have any
2) send everything to the cloud
3) send everything to a controller

I prefer that APs have enough oomph to get the job done if that’s the optimal place to do the work. There are times when using the cloud makes sense (distributed, analytics), there are times when using the AP makes sense (application visibility/control), and there are times when using a controller makes sense (2008-2009). #CouldntResist

I’ll summarize all of this by asking that prospective customers of Wi-Fi infrastructure remember that they will likely never use even a small fraction of the throughput capabilities of an AP. What will have a significant impact is Wi-Fi system cost, Wi-Fi system architecture, and network design. Don’t get duped by the loud, obnoxious marketing hype around the speed/throughput. Think twice, buy once.

 

802.11ac, 802.11n, Best practices, WLAN planning

Network troubleshooting in distributed Wi-Fi environments

November 20th, 2013

Wi-Fi is installed after everything else in the network is already set up – switches, routers, servers, firewalls, VPNs etc. Naturally, customers rely on their Wi-Fi solution provider to alleviate any network problems that arise during the Wi-Fi deployments, even though the problems are not necessarily Wi-Fi specific.

Network issues aren’t something new in any project. However, the troubleshooting task becomes challenging when it needs to be done remotely and when there isn’t much onsite IT help. This is often the case with the distributed Wi-Fi deployments. Also, due to the heterogeneity of the network infrastructure in many environments in the distributed vertical, sometimes very stealthy network problems are encountered. Take these recent troubleshooting examples which underscore these points.

Number Jumble in DNS Forwarding

In a recent distributed Wi-Fi installs that we were involved in, the AP would fail to connect to the cloud. After eliminating a few obvious possibilities, we found that the AP was failing to perform a DNS resolution. The customer was using Google DNS. So, we put the DNS request packet from the AP under the microscope and found it to be properly formatted. We did not have access to many parts of the customer’s network to view the logs. Then, one of us made an interesting observation – when the AP pinged something in the Internet, the AP would briefly succeed in performing the DNS resolution. Upon pursuing that lead, we found out that when there was no ping, the DNS request used source port 1024 and failed, but when there was a concurrent ping, it used source port higher than 1024 (since 1024 was taken up by ping) and succeeded.

Need Wi-Fi troubleshooting? Call up a networking Jedi!

Need Wi-Fi troubleshooting? Call up a networking Jedi!

That meant some network element in the packet path was blocking the DNS request with the source port 1024. There is no restriction like this in the DNS protocol on the source port number. Linux implementations have been known to follow the convention to use low ports only for Kernel privilege processes. Some network element in the packet path seemed to have incorrectly adapted that convention to some packet filter rule on the interface. Even then, it seemed the implementation glossed over the detail, since Linux privileged ports are below 1024, not including 1024. Patching the AP software to exclude port numbers below 1025 in the DNS requests solved the problem (though we and even the customer still do not know what was blocking the original DNS requests).

Grumpy RADIUS

In another case, we got panic call from a customer saying that putting an AP in their network disrupted the network. Everyone thought there must be some malformed packet coming out of the AP that some switch or router did not like. We examined several packets from the AP to ensure there was no rogue packet in there. Then the investigation moved to network servers, starting with DHCP and DNS, and we found them to be in good health. Then came the turn of the RADIUS server, which is where unusual activity was spotted. After the AP deployment, the RADIUS process showed frequent restarts. But why would that happen? After all, RADIUS requests from the AP were well formatted. Digging further, we discovered that the contractor had put in an incorrect RADIUS secret in the AP. Instead of gracefully rejecting requests coming from the AP, the RADIUS server process used to restart upon seeing the incorrect secret (and without writing any logs). Entering the correct RADIUS secret in the AP fixed the issue. Hopefully, the customer will now maintain or upgrade their RADIUS infrastructure.

Toast to Network Jedi

I have many such stories to tell and I am sure many of you too. The real heroes in troubleshooting stories like these are the engineers who jump in to resolve insidious problems during Wi-Fi installs. What is also impressive is that they do this in the networks that are completely new to them and often only remotely and partially accessible. My shout-out to all the networking Jedi for making Wi-Fi work in more networks every day!

 

 

WiFi Access, WLAN planning

11 Commandments of Wi-Fi Decision Making

September 4th, 2013

|

Are you considering new Wi-Fi deployment or upgrade of legacy system? Then you should be prepared to navigate the maze of multiple decision factors given that Wi-Fi bake-offs increasingly require multi-faceted evaluation.

|

Follow these 11 “C”ommandments to navigate the Wi-Fi decision tree:

|

  1. Cost

  2. Wi-Fi CommandmentsComplexity

  3. Coverage

  4. Capacity

  5. Capabilities

  6. Channels

  7. Clients

  8. Cloud

  9. Controller

  10. 11aC, and last but not least …

  11. seCurity!

 

|hemant C tweet

 

1) Cost:

|

Cost consideration entails both “price and pricing” nuances. Price is the size of the dent to the budget and everyone likes it to be as small as possible. Pricing is the manner in which that dent is made – painful or less painful (I don’t think it can ever be painless!). One aspect of pricing is the CAPEX/OPEX angle. Other aspects such as licensing, front loaded versus back loaded, maintenance fees etc. have been around for a long time, so I won’t drill into details of those other than to say that they exist and need to be considered. Enough said on cost.

|

2) Complexity:

|

Complexity consideration spans deployment, configuration and ongoing maintenance. One pitfall to avoid is to “like complexity in the lab and then repent it in the production”. Too many knobs to turn and tune, excessive configuration flexibility and exotic features are some of the things that can add to complexity. That said, complexity considerations cannot swing to the point of being simplistic. Rather, the balanced approach is to look for solutions that have mastered complexity to extract simplicity to meet your needs (borrowing from Don Norman’s terminology here).

 |

3) Coverage:

|

When you hear terms like neg 55, neg 60, neg 65, you know people are reconciling coverage expectations to the number of access points. There’s no explanation needed for how important the coverage is for your wireless network, but the important factor is that the coverage determines the number of access points needed to cover the physical area. At the planning stage, RF predictive planning comes in handy to estimate the coverage BOM (a site survey can complement it for sample areas during the evaluation stage).

|

4) Capacity:

|

While coverage determines how far, capacity determines how many or how much. Capacity determines how small or large cells can be. Using practical models for Wi-Fi usage, capacity objectives can be set and network design can be evaluated against these factors. Capacity also determines the number of access points needed to provide the desired capacity in the physical area. RF predictive planning tools can be invaluable during the evaluation phase for capacity estimation.

|

5) Capabilities:

|

By capabilities, I mean feature set. This is one of the most important aspects because this is where you ask the question: “Will the Wi-Fi serve the needs of the business?” This is very industry specific. Some features are extremely critical for one vertical, but won’t even be noticed in others. So, it’s important to identify both the features you care about and also those for which you don’t.  Once identified, you move on to thoroughly evaluate the ones you care about.

|

6) Channels:

|

One aspect of channels is making decision on how the RF network will be provisioned along the lines of 2.4 GHz and 5 GHz operation. There are advantages to 5 GHz operation, but 2.4 GHz is not EOL yet. How applications are split between the two bands determines the number and type of radios required in the design. Tools and techniques that are needed to plan, monitor and adapt to the dynamic RF environment are also an important consideration.

|

7) Clients:

|

Much of what is achievable in Wi-Fi network depends upon the capabilities of the client devices that will access the wireless network. One set of considerations is mainly around the radio capabilities of clients such as 2.4 GHz/5 GHz operation, number of radio streams, implementation of newer standards in clients etc. Another set of considerations revolves around the applications they run and the traffic profile these applications generate. Yet another set of considerations centers around the level of mobility of the clients. BYOD is another consideration that has become important in the the clients arena.

|

8) Cloud or 9) Controller:

|

Today, we see pure cloud architecture, pure controller architecture and also architectures confused between the two concepts. While vendors and experts spar over which is the right architecture for today’s and tomorrow’s Wi-Fi, evaluators should focus on comparing them based on their derived value. It is also important to understand what cloud and controller concepts actually mean from the data, control and management plane perspective. Cloud and controller are distinct ways of organizing overall Wi-Fi solution functionality.

|

10) 11aC:

|

Making judicious decisions on “what to deploy today or whether to upgrade now” is a tricky one. There are many views around it. One reason is because of how the features of 802.11ac are split between Wave-1 and Wave-2. It is also important to note that immediate 802.11ac benefits are application and vertical specific. Several practical network engineering considerations exist beyond the casual description of the new 802.11ac speeds that are often marketed. So, listen to vendors, listen to business needs, listen to experts, analyze yourself, and in the end, do what is the best for your environment and situation. Speed is nice IF it can be leveraged in practice!

 |

11) SeCurity:

|

Any information system sans security is worse than worthless – especially today. That said, level of security required by the wireless environment depends on factors such as the value of information at risk, compliance requirements and enterprise security policies. Desired security level determines the right mix of data inline security (encryption, authentication) and security from unmanaged devices (WIPS). Talking of WIPS, the biggest red flags to watch for are trigger happy solutions that generate false alarms, boast long list of ”popcorn” alerts and require excessive manual involvement in the security process.

letter spoonfull|

My hope is that these “C”ommandments will help serve as guidelines in your Wi-Fi decision making process. You can follow them in any order you like to ensure holistic evaluation of options before you. Every vendor, big or small, has sweet spots on some dimensions and not so sweet spots on others. So, despite what they tell you, nobody scores all A’s on all C’s. Hence one has to work on the evaluation criteria until the palatable scorecard is achieved consistent with requirements and budget.

 |

Additional References:

 

802.11ac, 802.11n, Best practices, WiFi Access, WLAN networks, WLAN planning , , , , ,

AirTight is Making Enterprise Wi-Fi Fun Again

August 19th, 2013

|

Anyone who knows me knows that I’m always looking way ahead, and it’s my opinion that AirTight Networks is uniquely positioned to take advantage of a major confluence of forthcoming Wi-Fi market changes and requirements. With

1) a scalable, plug-n-play, API-enabled, elastic cloud,

2) controller-less technology,

3) innovative and industry-leading security offerings, and

4) cost-effective, high-performance, feature-rich access points,

no other vendor is as well-positioned to take on managed services, plug-n-play enterprise Wi-Fi, and a wide variety of cloud services.

The need for uncompromising, flexible, and robust security (without the complexity that’s normally associated with it) has become a top-of-mind issue, and AirTight is the unmistakable leader in this area.

|

Why are so many enterprise Wi-Fi networks so broken and under-performing? The exact list is long, but the #1 reason, far and away, is that they are too complicated.

  • Complicated - Simple sign  Too complicated to learn.
  •   Too complicated to design.
  •   Too complicated to configure.
  •   Too complicated to deploy.
  •   Too complicated to monitor.
  •   Too complicated to upgrade.
  •   Too complicated to optimize.
  •   Too complicated to troubleshoot.

 

Who doesn’t constantly ask that their Wi-Fi system be more simple to deal with?  Come on, you know I’m right. Don’t even think about arguing with me on this one. I’ve posed this question to so many customers, VADs, VARs, and consultants that I’ve lost count. Too complicated usually means broken in one way or another.  How many single-AP Apple Airport networks do you come across that are completely messed up?  What… 0.000001%?  Why?  There’s hardly anything to misconfigure, and what little that is in the configuration interface is so intuitive that my mother could figure it out.

In a manner of speaking, I want my enterprise Wi-Fi to be much the same way (too easy to screw up), and of course, it should “just work”.

My friend Bradley Chambers likes to call it the 7S model:

|

 Simple - easy to design, configure, deploy, use, and troubleshoot

 funky orange wifi symbolSocial - integrated social media

 Smart - intelligent, cooperative network edge and cloud management system

 Secure - this applies to the cloud management and the product security features

 Scalable - unlimited is the only acceptable description

 Stable - adequate testing is done before product release, and it “just works”

 Sensible - cost effective and reasonably priced

|

Since most enterprise Wi-Fi networks are overly complicated, people make mistakes in the design, deployment, configuration, and so on.  Network managers do not have the time (and rarely the inclination) to spend most of their day messing with the Wi-Fi network. They have other things to do.

It’s easy enough to say “we simplify”, but to be honest, everyone has a different definition of what the word simple means. Simple is relative. I think that making a Wi-Fi system simple falls short. As a vendor, I think you know when you’ve arrived when your customers find your system downright fun. Fun to configure. Fun to monitor. Fun to upgrade.  And of course if something goes south, fun to troubleshoot.

|

Just imagine the scene…

|

“Hey Mike, we need to deploy three more SSIDs today.”

 ”Sweet! (fist pump)”

 |

No more flailing about in Wi-Fi UI hell. Experience the end of Wi-Fi as we know it. With its cloud-based simplicity, security, and automation,  AirTight is making Enterprise Wi-Fi fun again.

And, by the way, AirTight just launched a free AP trial for those of you tired of complex WLAN solutions.  Experience secure, cloud-managed Wi-Fi for yourself. 

|

AirTight: Wi-Fi that loves you back. 

 

|

802.11ac, 802.11n, WLAN networks, WLAN planning ,

Pleading the fifth at Wireless Field Day 5

August 15th, 2013

 

AirTight R&D and support teams, based in Pune (India), tune in live to watch WFD5.

AirTight R&D and support teams, based in Pune (India), tune in live to watch WFD5.

|

It’s not often that you get a group of Wi-Fi independent thought leaders together in the same room.  Last week, we had the privilege to address such a group at Wireless Field Day 5 (WFD5).  This was the first time that AirTight presented at the semi-annual event.  We’re hoping to be invited to the next one in February.

|

AirTight Networks to Make its Live Tech Field Day Debut at Wireless Field Day 5 in Silicon Valley

|

What made this event all the more interesting is that our session was streamed live over the Internet. An AirTight video archive was then created and can easily be referenced at any time from the Tech Field Day site.  In fact, all vendor presentations can be found here.

|The AirTight session started off with a welcome by CEO David King.  His talk provided a view into the richness and depth of the wireless industry and even included a reference to Dilbert Wi-Fi.  Following are a few tweets that reflect the sentiment around David’s introductory remarks.

|

wirelessguru tweet

Keith R Parsons tweet

 

 

 

 |

Stephen Foskett tweet

|

Next came a demonstration of the AirTight user interface and ease-of-use by Dr. Kaustubh Phanse, principal wireless architect and chief evangelist, and an analytics and social Wi-Fi demonstration by Sean Blanton, senior systems engineer.

These two demonstrations were then followed by a technical presentation on the AirTight cloud-based Wi-Fi management plane by Dr. Hemant Chaskar, VP of technology and innovation.  For more depth around what differentiates a cloud-based Wi-Fi management plane from traditional architectures, you’ll want to read this @CHemantC  blog post.

|

AirTight WFD5 picture archive by Jennifer Huber

 |

There was no shortage of questions for each of the presenters and it seems that the candor of AirTight answers was well received. The WFD5 delegates waste no time in voicing their opinions.  This blog post by Blake Krone was published a few minutes after the final ‘innovation’ presentation by CTO Pravin Bhagwat.  Ryan Adzima later published a post titled NMS UI and the product managers that hate us.

|

radzima

 

Each WFD5 delegate was given an AirTight C55 AP to test drive via AirTight’s cloud service.  If you’d like to experience AirTight cloud Wi-Fi for yourself, request your free AP today.

|Free AP Banner

|

Enquiring Minds Want To Know …

|

The delegates are a very social bunch and their questions and comments light up Twitter as the sessions progressed.  Their curiosity knows no bounds and it seems that nothing is off limits. There were even tweets asking about the meaning of the tattoo on Sean Blanton’s forearm.  If AirTight is invited to WFD6, Sean might be convinced to show them the one on his back …

And while we’re on the topic of questions, we’re wondering whatever happened to the AirTight “5”? We think that Lee Badman knows … but he’s pleading the fifth.

 

More on WFD5 and the complicated world without wires

|

 

802.11n, WiFi Access, WLAN networks, WLAN planning ,

Evaluating a Wi-Fi Solutions Provider? Make Sure They Talk SMAC

July 15th, 2013

|

Applying the Social, Mobile, Analytics and Cloud (SMAC) model to your Retail Wi-Fi Investment

|

Figure 1: Gartner Nexus of Forces is the convergence of social, mobile, information (analytics), and cloud to transform business and IT.

Figure 1: Gartner Nexus of Forces is the convergence of social, mobile, information (analytics), and cloud to transform business and IT.

Social, mobile, analytics and cloud (SMAC) technologies are high on everyone’s investment priorities list—so much so that SMAC has become the new enterprise IT model. Research firm Gartner refers to the trend as the Nexus of Forces, a convergence of technologies that is building upon and transforming consumer behavior and ushering in the next-generation of business technology.

 

“Although these forces are innovative and disruptive on their own, together they are revolutionizing business and society, disrupting old business models and creating new leaders,” says Gartner. Therefore, the SMAC model calls for evaluating individual technology investments by how well it helps you integrate social, mobile, analytics and cloud services to transform your enterprise.

 

According to RIS’s Store Systems Study 2013, retailers highest investment priority is mobile, and rightfully so. A lynchpin technology for enabling mobility in brick-and-mortar retail is Wi-Fi.

 

Does your Wi-Fi solution provider pass the SMAC test?

 

Here’s a few things to look for when evaluating Wi-Fi for large, distributed retail environments:

 |

Social Integration

 |

Social is a major driver of SMAC. It was largely people’s desire to socially interact with friends and family on the go that drove the rapid adoption of smart devices, so make sure social is integrated into your Wi-Fi solution. Social integration allows customers to login to your guest Wi-Fi via their Facebook, Twitter, LinkedIn or Google+ account, making it super easy and far more likely.

Retailers not only gain a mechanism for rapidly growing their followers and fan base with high-value users—those consumers who have already visited their store—but can now put a name to what was otherwise an anonymous shopper. Armed with this information, retailers can integrate an individual’s in-store shopping experience with her online habits and customer loyalty programs to send highly personalized and relevant, location-based offers, coupons or other information directly to her mobile device. The customer, in turn, can opt to share that information and positive brand experience with her own social network of friends and family. And the cycle continues.

|

Omnichannel Technologies to Maximize Holiday Sales and Profits | webinar via @RISnewsinsights

Date: Thursday, July 18, 2013 | 2:00 pm ET |  1 hour  (archive version will be available)

Moderator: Joe Skorupa, Editor-in-Chief, RIS News

Panelists: Robert Fort, Former CIO of Wet Seal and Kevin S. McCauley, Director, Retail Market Development, AirTight Networks

 

Secure Mobile

 |

8 Steps to Secure Retail Wi-Fi | AirTight INFOGRAPHIC

8 Steps to Secure Retail Wi-Fi | AirTight INFOGRAPHIC

You may be inclined to think that any Wi-Fi solution would meet the “M” for mobile SMAC requirement. However, in retail environments where payment information is exchanged over the network, secure mobile with a capital “S” is of paramount importance. As you investigate WLAN vendors, make sure they have a complete solution for PCI-DSS compliance and reporting. For large, distributed environments, security should be automated and simple to deploy, manage and maintain with little or no local IT support. Look for features such as automated scanning for detection of rogue devices or “man in the middle” attacks, and automated preventative measures and actions for immediately eliminating the threat.

|

Even environments that don’t yet offer guest Wi-Fi access should have a solution in place for dealing with bad guys who may be out to scam your customers and possibly harm your reputation. Therefore, look for solution providers who can offer you wired and wireless intrusion prevention that can evolve and scale to provide you with the access you’ll need when you’re ready.

|

Is Your Wireless Safe? |by  Airtight CTO Pravin Bhagwat via @QSRmagazine

|

Analytics

 |

Customer analytics provides valuable business intelligence to increase customer loyalty, engagement and revenue. However, because customer data comes from a large and growing variety of sources—through social interactions, loyalty programs, POS systems, online browsing history and in-store real-time browsing—no where is SMAC integration more important.

 

AirTight Social Wi-Fi Solution Brief

 

A good Wi-Fi analytics report should provide real-time and historical trends such as number of Wi-Fi user devices present in or near the store, type of device, where they are located, how long they linger, and at what time of day. It should also provide information on repeat visitors of specific stores and groups of stores. When integrated with social media, analytics become far more powerful and personalized, providing not only the identity of mobile in-store shoppers, but information such as “likes” and interests to help push highly targeted and relevant offers and information to your customers.

|

Cloud

|

Not all cloud-based Wi-Fi solutions are equal.  Look for a controller-less architecture that is purpose-built for large, distributed enterprises. Things to watch for:

 |

  • Scalability and multi-tenant support

Controller Wi-Fi, controller-less Wi-Fi, cloud Wi-FiThe solution should be able to scale to tens of thousands of locations or devices. A hierarchical location-based architecture should enable multi-tenancy (the ability to separate accounts, configurations and data) within a single customer account (e.g., corporate vs. franchisee, or across multiple brands)

|

  • Reliability

Your vendor’s globally distributed data center environment should offer four nines (99.99%) uptime and local and WAN-based high availability and redundancy. While managed via the cloud, all of your access points and sensors should be able to operate even when connectivity to the cloud is lost.

 

Airtight will be talking SMAC at #WFD5 | August 7-9 2013

Airtight will be talking SMAC at #WFD5 | August 7-9 2013

|

  • Location-aware centralized management

Web-based management should be simple and intuitive, and provide administrators with access and reporting based on their role and the locations that they manage.

|

  • Zero-touch provisioning

Solutions should be plug and play, requiring no IT staff at remote locations. Access points and sensors should be automatically discoverable and configured when connected to the cloud.

|

Focus on the Customer Experience

|

At the heart of the SMAC model is relentless attention to the customer experienceRetailers are strategically deploying SMAC across key business processes and technology deployments, combining the best of virtual and physical retail shopping to create data-rich, personalized channel-agnostic customer experiences.

At the heart of the SMAC model is relentless attention to the customer experience.

By focusing on the way customers like to shop and consume information, and enabling those experiences with technologies such as in-store Wi-Fi with integrated social, mobile, analytics and cloud services, forward-thinking companies will continue to compete in this rapidly changing digital world.

||

 According to the recent IBM study, From Transactions to Relationships: connecting with a transitioning shopper, what consumers want is a personalized in-store experience that not only mirrors the experience they get with online shopping, but is seamlessly integrated with their on- and offline shopping habits, preferences and history.

Dr.Nadia Shouraboura talks about how online and offline retail can come together to create the perfect shopping experience. 

Additional Information:

|

Webinars:

|

Other blog posts by @LinaArseneault

 

Best practices, mobile device management, PCI, WiFi Access, Wireless security, WLAN networks, WLAN planning , , , , ,

802.11ac (Wave-1): MORE Network Engineering Insights

June 24th, 2013

802.11ac more engineering insightsIn my previous blog on the 11ac series, I explored 80 MHz channel operation in 802.11ac in the context of data rate, OBSS (Overlapping BSS), network throughput, and auto-channel assignment.

802.11ac (Wave-1): Network Engineering Insights

In the present post, I explore the other speed factor of 1.33X that shows up in the Wave-1 data rate equation: (2.16 x 1 x 1.33) x 450 Mbps of 802.11n rate = 1.3 Gbps. This 1.33X factor is attributed to the new modulation technique called 256-QAM introduced in 802.11ac (802.11n had only upto 64-QAM). Consistent with the theme of this blog series that the data rate equation does not bring out critical network engineering aspects, this post explores 256-QAM from the enterprise network design perspective.

 

256-QAM causes step function change in data rate near the AP

 

There are two newly added MCS’s (Modulation & Coding Scheme) in 802.11ac.  They result in respective data rate increase factors of 1.21 and 1.33, over the highest possible data rate in 802.11n for a given channel bandwidth and number of spatial streams.

These two newly added MCS’s use the 256-QAM scheme, which requires about 5 to 7 dB higher SNR (which is a lot given that dB is logarithmic scale) compared to the least SNR at which the best MCS in 802.11n (64-QAM, R 5/6) can work with.

As a result, the 256-QAM can only be used close to the AP. From the network engineering standpoint, the key point to note is that 256-QAM to 64-QAM is step function change, that is, as you move away from the AP, the data rate drops in step function from 256-QAM rate to legacy 64-QAM rate.

This observation is important to quantify cell-wide benefit of 256-QAM.

|

256-QAM is a step function change in data rate

|

What is the cell-wide impact of 256-QAM?

|

In enterprise deployments, clients are distributed throughout the cell. In a sense, this is different from the home networking environment where many clients can be close to the AP. A well-known principle in 802.11 is airtime un-fairness, which means clients away from the AP consume more airtime due to their lower speed compared to those closer to it. By now, you probably can guess what I am getting at.

For illustrative purposes, consider four clients (let us call them C1, C2, C3, C4) at four distances from the AP, respectively, and having data rates (assuming 40 MHz channels and 2 antennas on clients) as follows:

  • C1 @ 360 Mbps (256-QAM rate with 1.33X data rate increase),
  • C2 @ 270 Mbps (maximum 64-QAM rate),
  • C3 @ 216 Mbps (another 64-QAM rate), and
  • C4 @ 108 Mbps (16-QAM rate).

I will compare this situation with the corresponding 802.11n data rates (no 256-QAM) at the same distances for the same clients:

  • C1 @ 270 Mbps (maximum 64-QAM rate),
  • C2 @ 270 Mbps (maximum 64-QAM rate),
  • C3@ 216 Mbps (another 64-QAM rate), and
  • C4 @ 108 Mbps (16-QAM rate).

Below is the diagram depicting total airtime saved due to the use of 256-QAM for clients close to the AP in the above example. Here, I have avoided using lower rates like 54 Mbps and 27 Mbps (which are for the QPSK and BPSK modulation schemes) for clients further away from the AP to favor 256-QAM. The saving in airtime will be distributed to the clients in proportions of their data rates.

 

256-QAM airtime distribution _ with_wihtout

|

The above example shows about 4% saving in total airtime for the cell when the client close to the AP can use 256-QAM.. Also a point to note here is that actual numbers of data rates and clients are not important and that relative proportions are important. You get the same saving number for the same relative proportions of the data rates.

|

More clients away than close (Area = Pi * Square of radius effect)

|

The area of coverage of the cell is proportional to square of distance from the AP (middle-school formula for the area of the circle).

So in reality, there are usually more clients away from the AP than as many close to the AP. This type of client distribution requires computation of weighted proportions of airtime consumption rather than simple proportions as I did above. With weighted proportions, the savings in total airtime due to the use of 256-QAM close to the AP are below 5%.

For example, with one C1-type client, two C2-type clients, three C3-type clients and four C4-type clients, the total airtime saving because of C1 being able to use 256-QAM comes out to be 1.5%.

|

Airtime fairness feature on AP

|

APs support airtime fairness feature which tries to prevent higher airtime usage by clients operating at lower data rates. Suppose the fairness feature is configured to equalize the airtime consumption across clients. Then, in the computation above (with simple proportions), without 256-QAM, airtime would have been equalized as 25% each for each of the four clients. When 256-QAM is used, only one of the 25% slices (representing client closest to the AP) see airtime reduction of about 25% (due to 1.33X data rate).

So when normalized over the entire cell, with equal airtime fairness implemented on the AP, the total airtime saving due to the use of 256-QAM near the AP, comes to about 6.25%.  As discussed earlier, in general there will be more clients away from the AP than those close to the AP. With weighted proportions computation as above, the total airtime savings is about 2.5%.

|

New radio implementations

|

As we can see from the previous examples, raising data rates of only those client that are close to the AP (like what 256-QAM does), results in relatively small total airtime savings (this reminds me of an analogy from popular rhetoric: “what does it mean to the society if the rich become richer”).From the network engineering perspective, the clients that are away from the AP need more help. One hope is that 802.11ac clients may have better radio implementation than the 802.11n clients. This may enable the 802.11ac client at a given distance to achieve better SNR than the 802.11n client at the same distance. Introduction of low density parity check (LDPC) codes introduced in 802.11ac could also help a bit there, but that alone does not seem to be adequate. However, whether the net SNR boost will be adequate enough to raise the client at least one level up in the data rate (i.e., one layer up in MCS), remains to be seen until real life test results are out.

Overall, we see that 256-QAM shows juicy 1.33X gain factor in the Wave-1 data rate equation. However, from the perspective of cell-wide impact, the airtime savings can be much lower. There needs to be a way to raise data rates of all the clients, particularly of those away from the AP, in order to achieve attractive airtime saving (and hence capacity and throughput gain for the cell). In that regards, 256-QAM seems to be better geared towards home networking than enterprise networking.

weigh your 11ac options via engineering insightsFor enterprise networking, we may have to rely on radio implementation improvements due to hardware and processing techniques enhancements over time, to be able to obtain blanket data rate increase over the cell. Alternatively, one can plan coverage of .11ac cells to raise the minimum data rate at the edge of the cell, but it has cost and co-channel interference considerations.

These network engineering insights are appreciated only if you think outside of the isolated data rate equation!

|

 

Addition Information:

|

802.11ac, 802.11n, Best practices, mobile device management, WiFi Access, WLAN networks, WLAN planning

How to implement BYOD with Wi-Fi / WIPS assist

June 18th, 2013

BYOD Bring Your Own Device

|

Wi-Fi has become the de facto access medium for smart mobile devices in enterprise networks. Sitting at the edge of the network, Wi-Fi can assist greatly in implementing secure and disciplined BYOD in these networks.

There is no one-size-fits-all when it comes to BYOD management in the enterprise. However, from my experiences working with Wi-Fi and WIPS deployments, I have seen certain features that are particularly useful for organizations in implementing BYOD. This blog post explores some of these in greater detail. |

 

1)      Monitor new devices entering Wi-Fi

 

Monitoring for new smart devices entering the network is a first and important step in the implementation of disciplined BYOD. Wireless clients connecting to Wi-Fi are fingerprinted using packet level and protocol level characteristics to identify smart mobile devices.

|

WPA2 alone is not sufficient to stop personal devices from entering the protected Wi-Fi network.

|Monitor new devices entering Wi-Fi

|

2)      Enforce pre-configured policies on new devices entering Wi-Fi

 

Once a new smart mobile device is detected in the Wi-Fi network, different types of pre-configured policies can be automatically implemented. For example, one policy would be to block or limit access to new smart devices pending authorization. The Wi-Fi/WIPS solution can facilitate such policy enforcement by blocking new devices from accessing the secure network or provide them only limited access (e.g., access to only Guest SSID) until they are approved by IT administrator. |

Devices pending review |

3)      Automated approval/onboarding of new devices on secure Wi-Fi

 

Using mobile apps provided by Wi-Fi/WIPS vendor:  With the rising volume of new devices entering the network, manual approval and inventory may prove to be cumbersome. Using onboarding apps provided by the Wi-Fi/WIPS vendor, this process can be automated. New smart mobile devices are redirected to a portal and upon installation of the onboarding app, devices are allowed to enter the protected Wi-Fi. The onboarding app facilitates automated inventory and tracking for smart devices after they are admitted into the secure network. This app can also automatically configure secure WPA2 settings on the device without administrator intervention.

| Onboarding with AirTight Mobile app

|

Using third party MDM agents: Many organizations deploy specialized MDM (Mobile Device Management) systems to manage smart mobile devices accessing corporate assets. Several MDM systems choices are available in the market. So, BYOD onboarding workflow in a Wi-Fi solution that facilitates device onboarding with third party MDM agents is useful. With this workflow, new devices attempting to connect the network without hosting the MDM agent prescribed by IT are detected and redirected to install the MDM agent. Upon installing the MDM agent, they are allowed to enter the protected Wi-Fi. A point to note here is that MDM alone does not complete the BYOD story, combination of MDM and Wi-Fi gatekeeping is what is required. This is because MDM can control only managed devices, but Wi-Fi/WIPS gatekeeping detects unmanaged devices and helps bring them under MDM control. Airtight Wi-Fi provides API to implement this workflow using third party MDM agents.

|

4)      Wireless security for the admitted devices

 

Once admitted into the network, the mobile devices need to be afforded strong protection from vulnerable wireless connections and wireless attacks including rogue APs, tethering, personal hotspots, Wi-Phishing, client connections to neighborhood APs, ad hoc connections, etc.  With BYOD, the sheer volume of wireless endpoints seen in the wireless environment is expected to triple or quadruple over next 2-3 years. As a result, fully automated strong WIPS, free from false alarms and not requiring excessive configuration and signature maintenance is needed to be the part of the Wi-Fi solution in order to implement truly secure BYOD. |

As we can see, enterprises can take advantage of many Wi-Fi and WIPS features to implement secure and disciplined BYOD in their networks. These features range from identifying new smart devices entering the network to assist in smooth onboarding of the new devices to securing the new devices once they are admitted into the secure Wi-Fi networks. So don’t get stressed by BYOD, there are Wi-Fi and WIPS to assist you.

|

Additional Information:

|

802.11ac, 802.11n, Best practices, BYOD, mobile device management, smartphones, WiFi Access, WLAN networks, WLAN planning