Archive

Archive for 2013

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

Get in the Game with Wi-Fi Managed Services, Part 2

November 14th, 2013

This is part 2 of my post on the managed service provider model in Wi-Fi. Click here for part 1.

Is Wi-Fi Ready for MSPs?

An important consideration when offering Wi-Fi as a managed service is whether or not the Wi-Fi solution you will choose is designed for it, both from the technical and business aspects. There’s far more to the selection process than meets the eye, and a few (of many) requirements might include:

  • Simplified equipment licensing procedures
  • Hierarchical and well-controlled super- and multi-tenant management capability
  • Management system simplicity, scalability and redundancy
  • Capability to manage distributed customers
  • Controller-less architecture to enable remote management with scalable economics (a requirement to make Wi-Fi managed services cost-effective)
Near-Zero Startup Cost MSP

Starting a typical MSP is a high-capex endeavor (data center space, servers, management software, equipment licenses, APs, etc.), which is why it is primarily the domain of larger companies. With manufacturer-sponsored equipment financing (like AirTight’s opex sales model) and resalable AirTight cloud management and services (such that the MSP doesn’t have to build their own cloud management system), the startup cost for getting your MSP on its feet just went to near zero. This means that every channel partner who wishes to engage in managed services needs only to:

  • Put together the appropriate customer contracts
  • Understand how to compensate their sales professionals
  • Understand how/why/when to sell managed services.
Leveraging the MSP model

Wi-Fi technology is now experiencing major upgrades more quickly than ever, and customers may not want to invest in technology for the full ~5 years of expected useful product lifetime. Instead of over-buying, they may desire, due to costs and product maturity, to deploy 802.11n today, and in a year deploy 802.11ac Wave-1, and in another year deploy 802.11ac Wave-2. With an opex sales model via an MSP, they can do exactly that – cost effectively and with minimal technical or logistical hassles. Given MSP’s engineering resources and significant vendor relationships, they are able to more readily research, test, and verify:

  • Proof-of-concept testing of chosen solutions (including software/feature updates)
  • Network design requirements: application performance, AP density, client/AP compatibility
  • Industry best practices: security, density, scaling
  • Industry regulations and reporting requirements (PCI, HIPAA, SOX, etc.)
  • The latest technologies and market trends: product features, integration work and competitive landscape

These items are of significant benefit to an MSP’s customers.

Other MSP Advantages for the Midmarket

The customer doesn’t have to worry about on-going employee training or which vendor’s solution is best at any point in time.

Should the need arise to resize or reshape the network (special events, network expansion, etc.), an MSP can readily accommodate this need as part of their normal management process.

MSPs offer the customer an SLA based on the customer’s needs (and of course the MSP’s ability to offer such SLAs). SLAs could be focused around (but certainly not limited to) the following:

  • Network uptime
  • Network deployment time
  • Throughput per device
Get in the Game!

As you can see, MSPs have a bright future serving midmarket customers. I leave you with this cartoon – ”Suddenly, everybody attacked the mid market…”, – and so can you!

get-in-the-game-MSP

It is my belief that no other Wi-Fi manufacturer, aside from AirTight, better enables its channel partners to take advantage of this radical market shift, since AirTight has engineered its cloud Wi-Fi solution around MSP enablement from the beginning. Agree or disagree?

Managed Service, WiFi Access

Get in the Game with Wi-Fi Managed Services

November 12th, 2013

This is part 1 on our two-part MSP series. Part 1 focuses on the basics of the MSP delivery, while part 2 will discuss how to make this model work for you.

Nothing’s much has changed since I last blogged about Wi-Fi managed services almost a year ago, other than that I now work for a different manufacturer. The reason for the longer-than-expected ramp-up time is that Wi-Fi manufacturers (in general) haven’t yet adequately equipped their channel partners to take advantage of this market trend. The slow ramp-up is over, and it looks like it’s a land grab of epic proportion… starting… NOW.  For those of you waiting on the sidelines, it’s time to get in the game.

Market Drivers for MSPs

msp-datacenterAs the challenges of delivering high-performance wireless access networks in the face of exploding user demands become ever more daunting to the average IT guy, midmarket CIOs are still having a difficult time of adequately staffing their IT organization. Gartner and I both still believe that midmarket companies should consider using Managed Service Providers (MSPs) to solve this problem.

Engineers who are well-trained and experienced in designing, deploying, troubleshooting, and maintaining enterprise-class Wi-Fi networks are still fairly scarce and expensive. MSPs can offer high-end engineering skills, paired with economies of scale (leveraging shared resources), to midmarket customers who would otherwise have to hire their own expensive, dedicated engineers; the alternative being to try their luck with general IT installation contractors that may not have the right Wi-Fi expertise in-house or the ability to adequately support the installation once it’s done.

The decreased costs and lower risks of outsourcing to an MSP, in combination with attractive SLAs, may in many cases be a significant competitive advantage to midmarket organizations.

How is an MSP Different from a VAR?

If you’re unfamiliar with MSPs and how they differ from your garden-variety value-added reseller (VAR), I’ll briefly explain. Your local VAR will happily sell you a Wi-Fi network (making a little profit in the process), and their hope is to add services (hence the “value added” portion of the name) around the sale of the equipment. Those services could be anything along the lines of design, surveying, installation, configuration, optimization, maintenance, troubleshooting, reporting, and more. These services can be offered as prepaid (for a certain amount of man hours per month/quarter/year with additional time being paid hourly/daily) or it could all be an hourly/daily rate.

With managed services, you may still have the option of buying/owning the network hardware/software (called a capex sales model, short for “capital expenditure”), but there’s often the option of an opex sales model (short for “operational expenditure”, more commonly known as “leasing”) as well. The most common question that arises with the opex sales model is “who is doing the equipment financing?” More on that topic later.

The real differentiator offered by an MSPs is in the level of service provided. MSPs do everything for the customer throughout the lifetime of the network (as it relates to the service they are providing) while VARs most often perform tasks on an as-requested basis. MSPs therefore often provide the customer with a Service Level Agreement (SLA) contract stating exactly what they will/won’t do and what the adverse ramifications (to the MSP) of not performing those tasks (as stated in the contract) will be.

VARs MSPs
Scope design, installation, configuration, light helpdesk all of that plus full responsibility for on-going operation of the network, often including applications riding on top of it
Pricing Models primarily 1x costs (capex) with small (~10%) annual maintenance fee can also offer opex-only model, on per-user or per-network-node per month basis, as an alternative to capex + operational fee model
Guarantees typically commit to performance metrics at final acceptance of network install; maintaining network performance over time is customer’s responsibility offer service-level agreements (SLAs) for install time, network uptime, and possibly other performance metrics

MSPs will be managing, monitoring, and troubleshooting the network remotely (in the large majority of cases), they must choose technology solutions that lend themselves to this scenario.

How Can a Manufacturer Support You in this Model?

Manufacturers differentiate themselves in a number of ways:

  • Specializing on various aspects of the technology, such as performance, architecture, ease-of-use, or cloud services
  • Having a broad product portfolio: Wi-Fi, switches, firewalls, and routers
  • Offering varied sales models, from standard capex to 100 percent opex
  • Focusing on assembling solutions for vertical markets, rather than selling “horizontally” across various markets

Channel partners – distributors and resellers – are also looking for additional ways to differentiate above-and-beyond the manufacturer’s own technical or business-related advantages. Given the model’s inherent advantages, one valuable way to set themselves apart from the crowd is to additionally offer Wi-Fi as a managed service, either in a capex + service or even full-opex sales model.

  • In a capex model, the customer buys the equipment from the MSP and then additionally pays the MSP for their services (design, survey, install, integration, optimization, reporting, troubleshooting, etc.).
  • In the opex model, there are a variety of nuances of how an MSP might go about a sale, but most commonly, the APs are “leased” to the customer for a contract period (with periodic payments), and the customer is then charged for those same services (as previously mentioned) – either up-front or rolled into the periodic payments.

In part 2 of this post, we will discuss how to determine if a Wi-Fi solution is ready for the MSP model, how to get started, and how to sell the model to your customers. 

Managed Service, WiFi Access, WLAN networks

Wi-Fi Speeds-n-Feeds Are So Old-school

October 30th, 2013

Speed-n-feeds are not the future of enterprise Wi-Fi. Speed-n-feeds are like my grandmother’s potatoes. I’ll explain.

Ricotta-orange-sweet-potato-cakes

Speed is a given. Speed is a commodity. This is what you talk about when you have nothing else to offer, such as system intelligence. Some companies keep trying to rehash the speeds-n-feeds story like my grandmother used to treat potatoes. First, you’d have baked potatoes. If you didn’t eat all of them, the next night, you’d have mashed potatoes – made from those same potatoes, of course. If there happened to be any left-overs after that, you’d have fried potato cakes the next night. Believe me, the list of how those potatoes could be served was endless until those potatoes were gone. Same potatoes, different day.

With 802.11ac, networks have plenty of speed. In fact, I will bet you a cold beer that far more bandwidth goes unused on a daily, hourly, and per-minute basis than is ever used – even with an 802.11n network. You would be hard-pressed to find an AP in any enterprise environment that exceeds an average of 10% of its throughput capability when averaged over a normal 8-hour work day. If you find even one, please give me a shout with statistical proof. I’m interested to see that data.

There is Wi-Fi bandwidth to spare within most enterprise networks that have 802.11n or 802.11ac technology. The bottleneck isn’t in the radio capability, the architecture, the channel airtime, the AP CPU power, or even the available spectrum. The only exceptions are major interference sources, which can affect channel airtime and available spectrum, but that’s off-topic because you don’t design capacity around interference sources.

If there’s an actual speed bottleneck anywhere, it’s found in the battery life of mobile devices, which causes the use of single spatial stream (1SS) radios. Truth be told, even mobile devices using 1SS are fast, ranging from 65 to 433 Mbps, with about half of this data rate being considered usable throughput.

If you have some kind of crazy high-density scenario, sure, you could potentially run into an airtime bottleneck on specific APs at specific times, but that’s a sub-one percent use case issue in most enterprises, and buying a entire solution around a sub-one percent use case seems silly given the price multiple that you are apt to pay.

Most vendors are still building wave-1 802.11ac APs, and the industry is already talking about forthcoming wave-2 technologies, which are more than a year away, highlighting the marketing frenzy around performance. Look, I’m not against performance, but I’m saying that it’s far from the most important consideration.  In fact, at this point, it’s pretty far down the list.

Well, since there’s plenty of speed, what aspects are more important?

  • Solutions focused on vertical markets
  • MSP (managed service provider) enablement
  • Simplicity and intuitiveness of use and deployment
  • Sales model and process: capex, opex
  • System security, redundancy and stability
  • System maintenance, monitoring and compliance reporting

Those are just a few, but they are enough to point out that all of the hoopla around “just speed” is off-target. Almost any enterprise vendor can now provide reasonable connectivity, and they have the reference customers to prove it. Therefore, winning in the market is no longer just about connectivity, but rather about solving customer problems by providing a focused solution.

You like apples? ;)

/Image via foodieandfellow.com. For an uncommon twist on potato cakes, get the recipe: Orange ricotta sweet potato pancakes 

802.11ac, 802.11n, WiFi Access

Bang for the buck with explicit beam forming in 802.11ac

October 16th, 2013

 

Bang for the buck with explicit beam forming in 802.11ac

802.11ac has brought with it MIMO alphabet soup … spatial streams, space-time streams, explicit beam forming, CSD, MU-MIMO. Alphabet soup triggers questions to which curious mind seeks answers. This post is an attempt to explore some questions surrounding explicit beam forming (E-BF) that is available in Wave-1 of 802.11ac. E-BF is a mechanism to manipulate transmissions on multiple antennas to facilitate SNR boosting at the target client.

How is E-BF related to spatial streams?

E-BF is a technique different from spatial streams. E-BF can be used whenever there are multiple antennas on the transmitter, irrespective of the number of spatial streams used for transmission.

In the transmission using multiple spatial streams, distinct data streams are modulated on signals transmitted from distinct antennas. The signals from different antennas get mixed up in the wireless medium after they are transmitted from the antennas. The receiver uses signal processing techniques to segregate distinct data streams from the mixture. The ability to separate these distinct data streams from the mixture is dependent on the channel conditions between the transmitter and the receiver (to be able to isolate `S’ streams at the receiver, the channel matrix needs to have rank of `S’ or more). There is no channel dependent processing of signal at the transmitter. Receiver performance is channel dependent. Some key points regarding multiple spatial streams (spatial multiplexing) are:

  • To support `S’-stream transmission, both AP and client must have at least`S’ antennas
  • Rich scattering environment (e.g., indoor) is conducive to give high ranked channel matrix
  • There is no need to send channel feedback from the receiver to the transmitter.

In the transmission using E-BF, the spatial streams are pre-processed (and pre-mixed) to match them to the channel characteristics from the transmitter to the receiver and the output of the pre-processor is transmitted from different antennas. Feedback from the receiver about the  channel characteristics is used in pre-processing. For practical implementation called ZF (Zero Forcing) receiver, E-BF causes SNR boosting for the spatial streams at the receiver. Some key points regarding E-BF are:

  • Feasible with multiple antennas on the AP, irrespective of the number of spatial streams
  • Affects SNR of spatial streams at the receiver
  • Requires channel dependent pre-processing of signal at the transmitter
  • Requires feedback on channel characteristics from the receiver to the transmitter
  • Does not require multiple antennas at the receiver.
When is E-BF truly beneficial?

In general, E-BF is truly beneficial when the number of spatial streams in use is less than the number of antennas on the AP. In Wi-Fi, this most commonly happens when the client has less number of antennas than the AP. For example, most smartphones and tablets have only 1 antenna on them.

Stream vs beam tradeoff:

For the example of 3-stream AP and 3-stream client, adding E-BF on top of 3-stream transmission may not give significant benefit. This is because, with E-BF different spatial streams typically experience unequal boost in SNR. The SNR can be significantly boosted for some spatial streams with E-BF. On the flip side, there will usually also be some spatial streams for which the SNR boost is not significant. Or, it could even be degradation of SNR for some spatial streams compared to the case when E-BF is not used. To be precise, the SNR boost for each spatial stream is dictated by the corresponding singular value of the channel matrix and the singular values of the channel matrix range from high to low for practical channels (E-BF is based on technique called Singular Value Decomposition or SVD). Couple this with the fact that practical implementations use the same MCS on all spatial streams. So, this means either using the MCS supportable by the weakest SNR spatial stream for all spatial streams or using high MCS for the strong streams and dropping the weak streams. There is excellent explanation of this tradeoff  in the book by Perahia and Stacey in Chapter 13 (if you are up for reading some math!).

However, if 3-stream AP can support only 1-stream transmission to the client, E-BF can give significant gain. This is commonly the case with smart devices which have only 1 antenna on them. In this case, the single stream will most likely get boosted in SNR and there isn’t another stream to counter the SNR boost.

How much overhead does E-BF feedback cause on wireless bandwidth?

E-BF requires feedback from the receiver to the transmitter about the channel characteristics. In order to trigger this feedback, the transmitter sends sounding packet to the client. Client performs channel measurements on the sounding packet and responds to the AP with the channel feedback. A question that often comes up in E-BF is how much of a wireless link overhead the E-BF feedback report would cause. To answer that question, take a look at this spreadsheet. From this spreadsheet, it appears that the feedback overhead is relatively small (only about 0.1% of airtime), particularly for the case where E-BF is going to be most beneficial, e.g., 3 or 4-antenna AP talking to 1-antenna client.

All factors considered, E-BF appears to provide benefits for smartphones and tablets, which typically have only 1 antenna and hence cannot support multiple spatial streams when connected to the 3 or 4-stream AP. On the other hand, when there are multiple antennas on both sides of the link (such as a 3 or 4-stream laptop connected to the 3 or 4-stream AP), spatial multiplexing without E-BF can be as good as one with E-BF. These are the inferences drawn from MIMO principles and it would be interesting to see if they match up with measurements from the practical Wave-1 environments.

Earlier Posts in 802.11 Network Engineering Series:

 

802.11ac, 802.11n, WiFi Access , , ,

Hunting down the cost factors in the cloud Wi-Fi management plane

October 3rd, 2013

 

Mature cloud Wi-Fi offerings have gone through few phases already. They started with bare-bones device configuration from the cloud console and over the years matured into meaty management plane for complete Wi-Fi access, security and complementary services in the cloud.

CostAlongside these phases of evolution, optimizing the cost of operation of the cloud backend has always been important consideration. It is critical for cloud operators and Managed Service Providers (MSPs). This cost dictates what end users pay for cloud Wi-Fi services and whether attractive pricing models (like AirTight’s Opex-only model) can be viable in the long run. It is also important to the bottom line of the cloud operator/MSP.

Posed with the cost question, one would impulsively say that cost is driven by the capacity in terms of number of APs that can be managed from a staple of compute resource in the cloud. That is an important cost contributor, but not the only one!

 

What do the cost models from cloud operation reveal?

 

We have monitored cloud backend operation costs for past several years. Based on that data, we have built some cost models. These models have led to the discovery of factors that are significant cost contributors. Identifying the cost component is a major step towards reducing it. The cost reduction is often implemented by the combination of technology and process innovations.

 

Draining the cost out of cloud

 

Scalability

This one is no brainer for anyone with head in the cloud. Scalability generally refers to number of APs that can be managed with a unit of compute resource. Higher scalability helps reduce the cost. Enough said.

Provisioning

As the customers of diverse scales (10 APs to 10,000 APs) are deployed in the cloud and at diverse paces, it often results into unused capacity holes in the provisioned compute resources. The capacity holes are undesirable, because the cloud operator or MSP has to pay for them, but they don’t get utilized towards managing end user devices.

The unused capacity problem needs to be solved at two points in time: Initial provisioning and re-provisioning. Clearly, when new customers are deployed, you try to fit them in the right sized capacity buckets. Assuming they love your product, they will then deploy more and start to outgrow their capacity buckets (but you also cannot over-provision, else there will be capacity hole from the beginning). This is the re-provisioning time. At that time, the cloud architecture and processes need to be able to seamlessly migrate customers to bigger capacity buckets.

Personnel

The very reason customers have chosen to go with cloud is because they want plug-n-play experience. As such, the patience level of the cloud customer is often lower than the one choosing the onsite deployment option. This necessitates higher level of plug-n-play experience to avoid support calls.

There are various points in the life cycle that have high tendency to generate support calls.  One point in time is when devices connect to the cloud, or let’s say, not able to connect to cloud. Another critical time is during software upgrades. The issues also often arise during re-provisioning as discussed above when customers are migrated between compute resources. The cost of attending to support calls can be a significant factor if these experiences are not super smooth. Additional complexities arise when APs are sold through channel, but cloud is operated by vendor or another MSP.

The pricing logic behind reducing personnel cost at MSP is as follows. The end user is eliminating the onsite personnel cost by migrating to cloud, and hence paying less on TCO basis. When the experience is not smooth, this cost is transferred to the personnel at the cloud operator or MSP. The cloud operator and MSP cannot make money if they pick up significant part of this cost on their head.

Latent Resources

Certain features such as high availability and disaster recovery have potential to give rise to latent resources. Latent resources are different from capacity holes discussed before. Latent resources are like insurance in that they don’t get utilized most of the time, but they need to be maintained in great shape. Brute force implementation of these redundancy features has been found to be significant cost contributor to cloud operation.

For any cloud services platform, the above pain points are exposed after years of operational experience and teething pain with diverse customer deployments. That is why, it would be appropriate to say that there are two parts to the viable cloud operation – one is the computing technology that enables complete management features and the other is operational maturity. You overlook any one of them and the cloud can become unviable for operator/MSP and customers in the long term.

 

Additional references:

Wireless Field Day 5, AirTight Cloud Architecture video

Aruba Debuts Bare-Bones Cloud WLAN at Network Computing by Lee Badman

Next generation cloud-based Wi-Fi management plane

Controller Wi-Fi, controller-less Wi-Fi, cloud Wi-Fi: What does it mean to the end user?

AirTight is Making Enterprise Wi-Fi Fun Again

Different Shades of Cloud Wi-Fi: Rebranded, Activated, Managed

 

802.11ac, 802.11n, Cloud computing, WLAN networks , , , , , ,

MU-MIMO: How may the path look like from standardization to implementation?

September 26th, 2013

In earlier blog posts on 802.11ac practical considerations, we reviewed 80 MHz channels, 256 QAM and 5 GHz migration. Continuing the 802.11ac insights series, in this post we will look at some practical aspects of MU-MIMO, which is the star attraction of the impending Wave-2 of 802.11ac.

 

MU-MIMO mechanics and 802.11ac standard

 

Illustration of 802.11ac MU-MIMO

Illustration of 802.11ac MU-MIMO

At a high level, MU-MIMO allows AP with multiple antennas to concurrently transmit frames to multiple clients, when each of the multiple clients has lesser antennas than AP. For example, AP with 4 antennas can use 2-stream transmission to a client which has 2 antennas and 1-stream transmission to a client which has 1 antenna, simultaneously. Implicit requirement to attain such concurrent transmission is beamforming, which has to ensure that bits of the first client coherently combine at its location, while bits of the second client do the same at the second client location. It is also important to ensure that bits of the first client form null beam at the location of the second client and vice versa.

 

What does 802.11ac standard offer for implementing MU-MIMO

  •  The standard provides Group ID Management procedure to form client groups. Clients in a given group can be considered together for co-scheduling of transmissions using the MU-MIMO beamforming.
  • To be able to perform peak/null adjustments in MU-MIMO beamforming as described above, the AP needs to have knowledge of Tx to Rx antennas channel matrix to each client in the group. For this, the standard provides well defined process for channel learning wherein AP transmits sounding packet called as NDP (Null Data Packet) to which clients respond with channel feedback frames (this is called explicit feedback mechanism).

 

 What the standard does not specify

 

There is more to MU-MIMO implementation that is outside of the scope of the standard. The true promise of MU-MIMO is also dependent on these additional implementation factors:

  •  AP has to identify clients that can be co-scheduled in a group. How to form these groups is implementation specific. It is dependent on prevalent channel conditions to different clients. AP will have to make smart decisions on group formation.
  • AP has to keep track of channel conditions for clients in different groups by sending regular sounding packets and receiving explicit feedback to the sounding packets from the clients.  Various implementations may differ based on how frequent channel learning is required in them. Frequent learning increases channel overhead, but may result into cleaner (non-interfering) MU-MIMO beams. Slow learning can result in stale information thereby causing inter-beam interference during concurrent transmissions.
  • When channel conditions change, re-grouping of clients is required. Implementations can differ based on re-grouping triggers and method of re-grouping.
  • Implementations can also differ based on how total antennas on AP are used for beamforming within any given group.
  • The performance of MU-MIMO also depends to some degree on the client side implementation. For demodulating the MU-MIMO signal, clients can implement additional techniques such as interference cancellation to eliminate inter-beam interference.
  • The formation of MU-MIMO groups at physical/MAC layer has to also coincide with traffic and QoS requirements of the clients at higher protocol level.

Practical impact

Practical implementation aspects of MU-MIMOThe above considerations are at practical implementation level. Many of them are in the domain of chip design. How well different chip vendors address them could differentiate them from one another in the MU-MIMO era.

They can also impact Wi-Fi chip design paradigm, which traditionally used similar designs for AP and client radios. With MU-MIMO, there will be bulk of tasks that will be performed at AP, resulting in significant design differences between AP side chipset and client side chipset.

Due to all the nuances of implementation and sensitivity to channel conditions, comparing different MU-MIMO implementations in practical network is difficult task. Notwithstanding, I can imagine MU-MIMO becoming table stake in RFPs after Wave-2 arrives, to which everyone will answer “yes” without heed to the exact implementation details. :-)

One radical thought

Given the cost and complexity of chip level tasks required in MU-MIMO, could there be some chip family which may just use all antennas on the AP to form beam to single client at a time. That is, sequential SU-MIMO, instead of parallel MU-MIMO. What will be pros and cons? Will MU-MIMO be only incrementally or significantly better than sequential SU-MIMO? Time will tell.

Devil is in Detail!

 

Addition Information:

 

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

Blackhat 13 Wi-Fi Security Reports and Nuances of Detection Methods

September 12th, 2013

|

blackhat USA 13Shortly following the conclusion of Blackhat’13, a few articles came out reporting wireless scanning data from the venue.

  Inside the Black Hat 2013 Wi-Fi Network

  Karma is a …Errr, What We Learned at BlackHat 2013 

 

Both reports state that many security relevant events were detected in the Wi-Fi traffic during the conference. Given that Blackhat is attended by security experts, ethical hackers and just plain security geeks, finding security signatures in the traffic is not uncommon. Nonetheless, I think a few things still need to be matched up in these stats before arriving at sound conclusions.

|

1190 rogue devices detected compared to 1300 legitimate devices in 24 hours:

|

One of the articles states that: “It’s rather interesting to see an almost equal amount of rogue devices to real ones, and that is very unique”. What would be good to know is how they define ”rogue”. Depending on how you define rogue, you can call anything from a normal friendly device to a real threat posing device as a rogue.

I suspect that the definition for rogue used in the context of this report is so broad that it is classifying just about every wireless device unknown to the scanning system and seen in the airspace as rogue. But then, it is not clear why such an observation is considered “unique”. This is because, almost everyone attending Blackhat carries multiple Wi-Fi enabled devices and we cannot expect them to register each of their devices with the scanning system.

From the security perspective however, it is important not to get lost in definition of rogues, but be able to detect straight up genuine rogues (aka security threats) and not raise false alarms on normal wireless activity.

 

Fast WEP Crack (ARP Replay) Detected

|

The report also cites “most likely a security vendor demonstrating a tool”. What is perplexing is why Blackhat attendees still have interest in WEP crack tools or their antidotes, especially given that WEP has been beaten to nail and is now mostly irrelevant.

Or, it could point in the direction that the Wi-Fi community has done such solid job with security and WPA2 that hackers still think that they have to make hay out of WEP.

There is also a third possibility; that these ARPs are just part of normal Wi-Fi traffic that correlates with the signature of WEP cracking detection.

|

Spoofed MAC Address

|

Both reports state several occurrences of MAC spoofing. I suspect that these inferences are based on sequence number anomalies that were detected in the traffic. In fact, the video in one of the reports explicitly calls out sequence number anomalies. However, it’s important to note that sequence number anomaly also routinely happens due to normal traffic patterns.

Common reasons include :

  • sequence numbers fall in range 0-4096, so they wrap around very quickly making the wrap around appear like sequence number anomaly,
  • radios routinely skip sequence numbers due to implementation nuances,
  • intermediate frames may be missed because of device coming and going out of coverage making it look like a sequence number anomaly.

MAC spoofing should only be concluded after all these possibilities are eliminated.

|

Signatures and Anomaly Detection

|

Similar analysis can be performed for other anomalies detected in Blackhat traffic. In fact, this kind of analysis can be performed for several security alerts in many scanning tools and wireless security systems (may be another blog some day, I have many amusing stories to tell about these alerts :-)). The key take-away is that many times there is a leap from signatures and anomalies detected to inferring the presence of a genuine security relevant event.

Bubbleman path optionsWhose job is it to make this leap: system or admin? The need to make the leap gives rise to false alarm problem. Imagine how difficult the job of the security admins becomes when this happens in the enterprise setting! All of a sudden, the alerts also need to be chased and mitigated, not just documented in reports! These admins are also presented with the challenge of defining and tuning thresholds that are right for their environments. If admins are unable to filter false alarms and/or not get to the root causes of steady stream of alerts, it eventually leads to frustration and turning off the security system.

|

Policy Enforcing WIPS

 |

An alternative to signature and anomaly based system is policy enforcing WIPS. By de-emphasizing signature and threshold anomalies, and instead focusing on auto-classification and intrusion prevention, the policy enforcing WIPS offers strong security without overheads of threshold configuration, signature maintenance, false alarms and manual intervention.

So, to reiterate the meta level point about Wi-Fi security: “Intelligent security algorithms tall pole for effective WIPS. Dedicated scan radios otherwise only overwhelm admins with data”.

|

Hemant tall poll tweet

Wireless security , , , , , , ,

Get Soaked in the Future of Wi-Fi

September 5th, 2013

|

AirTight Networks is armed with Wi-Fi of the future, and blasting the message out through social media.

 |

Have you ever noticed that there always seems to be a disconnect in the Wi-Fi industry whereby vendors build and sell their products based on hardware capabilities, tech specs, and geeky feature sets while customers ultimately evaluate products based on how the solution fits with their organizational objectives? That’s a problem.

|

The Wi-Fi market is on the cusp of a second-wind of tremendous growth that will be driven by focusing product solutions on the tailored needs of customers in every vertical market.  However, this is a departure from the status-quo as historically the Wi-Fi market has grown by pushing products (not solutions) based on the latest hardware enhancements and improvements in speed that have come with each iteration of the 802.11 standard. But that model is breaking down as the technology matures, and hardware differentiation alone is very minimal. And customers are demanding more tailored solutions as their own markets evolve into a mobile-enabled workforce and customer experience.

|WiFuture tweet

|

What’s exciting is that AirTight is already delivering Wi-Fi of the Future (#WiFuture if you’re following along on Twitter). We provide tailored solutions that include social Wi-Fi integration that enable retailers to engage consumers and provide enhanced customer service, presence and location analytics to understand and adapt to customer behavior in-store, and the most robust wireless security solution on the market to secure data well beyond basic PCI compliance requirements. And that’s only the beginning.

 |

AirTight is building solutions that enable the Wi-Fi of the future through:

|

A Software-Centric Approach – leveraging the rich data analytics available through an intelligent access network, and software defined radios that enable flexibility of hardware use for client access, security monitoring, and performance analysis.

|

|Intuitive User Experiencemaking Wi-Fi simpler to deploy and troubleshoot so the network isn’t broken or under-performing.

|

Operational Expense Model – enabling customers to acquire the latest solutions without breaking the budget.

|

Mature Cloud – that is truly elastic with both public cloud and private cloud options, enabling easy expansion to meet growing network demands without causing unnecessary retooling or plumbing of the existing network. Mature cloud offering also enables the coming wave of Managed Service Providers (MSPs) who will serve the mid-market.

|

A Culture of Listening – to customers, partners, and industry experts in various industries so that we understand the business drivers for technology solutions and ensure we build products that deliver on those needs.

|

|

@AirTight: Soaking the Industry in the Future of Wi-Fi!

|

WiFuture SuperSoaker|

We are also building an incredible team of industry experts to blast this vision to the market through social media.  AirTight is armed with Super Social experts, kind of like those old Super Soaker water gun blasters we all loved from a few decades ago (has it been that long already!). The tank is full of energy and innovation, and the social media team at AirTight is at the trigger!

|

So, are you ready to blast away your Wi-Fi woes? Don’t get stuck on the wrong side, soaked and wet in yesterday’s technology.

 |

||

|

802.11ac, 802.11n, WiFi Access, Wireless security, WLAN networks ,

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 , , , , ,