Aruba Tech Field Day - 802.11ac Product Announcement

-

Yesterday was the official launch of Aruba's journey in to the world of 802.11ac with their online (and real-world) Tech Field Day event where they presented their products and strategy for 11ac. I was a virtual participant, watching from over here in the UK. I have to say up-front that I do not currently supply or support Aruba products, but was very interested to hear more about their views on 802.11ac, together with their product offering. There was a lot of ground covered, but here a few (brief) notes of things that I found of particular interest for the sessions I managed to view.

802.11ac

There was a very informative and lengthy discussion around 802.11ac technology, together with the lessons learned by Aruba in their testing to date. I won't cover all points here, but the headlines that stuck in my mind were:

  • Smartphones/tablets will continue to be primarily single stream, capable of 80MHz bonded channel support
  • Although 11ac brings significant speed advances, it's not the speed itself which is the advantage, it's the increase in efficiency of the WLAN which is the big win. The faster a client can get on the WLAN, send its data, and then get off, the more clients will be able to use the WLAN (which remains a shared medium). This will help to meet the growing demand for WiFi capacity
  • The highest "headline" speeds of 802.11ac will only be achieved by clients being in close proximity to an AP. The more complex modulation and signal processing required means that excellent signal quality (e.g. through excellent SNR levels) to achieve the higher speeds.
  • Sticky clients continue to be an issue (see "ClientMatch" below), which can significantly impact the efficiency of a high density WLAN. As client speeds drop as they move away from an AP, causing a bottleneck for other clients on the same AP that they are "stuck" to.

ClientMatch

A mentioned above, Aruba highlighted the ongoing issue with "sticky clients". These are clients that initially associate with an AP and then, despite 'better-choice' APs being available, remain associated as the client moves away from it. The issue with this is that the client speed will drop as the signal level falls, so that it is transmitting at lower speeds and impacting the efficiency of other clients using that same AP. If  clients can be made to prefer (and roam to) a more local AP, that will facilitate a better link speed and WLAN efficieincy, together with all of the efficiency gains that this will bring.

Aruba have a 'patented' technology, called ClientMatch which apparently looks at things from a client point of view and can 'steer' clients to better-choice APs. This technology can apparently work for all types of (legacy) client, but works best on more recent types of client that support newer 802.11 features such as 802.11k/v.

Reading between the lines, I think it analyses signal quality and signal levels from clients (at the AP end of things), together with 802.11k/v information to make some decisions about how things are looking from a client's point of view. Then, somehow (presumably through band steering and ignoring probes etc. from clients below pre-defined signal thresholds) it 'steers' them to a better AP.

We all know the types of information that are available to an AP from clients and the limited amounts of information that clients themselves will supply or act on. So, it's hard to see what there is here to actually patent. Unless there is some type of agent installed on the client (which there isn't in this case), what other unknown (patentable) mechanism could possibly be at work here? Apart from some 'secret sauce' decision making from the WLAN point of view, using known measurements and techniques, it's hard to understand what can be so unique about this. To be honest, without more information, I'm struggling with the concept of a unique offering here...

Access Points

Early on in the proceedings, Aruba presented their new 11ac access points: the AP220. There are two models, one with internal and one with external antennas. The units they had on display at the event were very impressive looking. They looked relatively light-weight (judging by the way they were being handled) and they appeared pretty sleek, as they have now dispensed with the usual air-vents to meet the 'wipe down' needs of the healthcare sector.

The AP has 2 Gigabit Ethernet ports to cater for the theoretical throughput speeds that can achieved by an AP with 2 radios (1 x 5GHz 11ac & and  1 x 2.4GHz 11n). I didn't quite get the information around the power requirements (i.e. 802.3af vs 802.3at), but looking at the datasheet, it looks like it can run in an 'Efficient Mode' with an 802.3af POE port and full funtionality mode with an 802.3at POE port. The detail on how the 2 gigabit Ethernet ports will be used (i.e. load balancing or a true trunk) was also unclear (this is still TBA on the datasheet I am looking at...).

The guys from Aruba pointed out that the AP uses less power than 'other solutions which require a plug in module' (i.e. Cisco). But, from what I see so far, both solutions require a full 3at POE port to operate with full functionality, so, I don't really see an advantage there..?

They also said that in their experience to date, you can pretty much do a one for one swap out of 11n APs for 11ac, as the general coverage patterns were broadly similar.

Lync

A Microsoft representative provided an excellent presentation around the Microsoft Lync product, which was fascinating for those of us (OK, maybe just me) who aren't that familiar with Lync. He described the challenges of trying to prioritise the different traffic flows that originate from a Lync client.  

The Lync client itself may be a number of form factors (laptop, tablet, phone), which may be the source of data, voice or video traffic. Trying to configure the QOS requirements for just those traffic types is a challenge, but throw in the fact that there is signalling traffic, some traffic is encrypted and some protocols do not use well known port ranges, and you have a whole heap of trouble.

He then went on to describe how Aruba have become a certified Microsoft Lync partner, allowing them to have access to an API that is made available from a Lync server. Having access to the API means that the Aruba wireless LAN controller can exchange information and drill down in to the detail of each Lync session, allowing decisions (such as QOS prioritisation) to be made as required. Apparently, Aruba and Microsoft have invested a lot of time in testing this exchange of information across the API, which allows better decisions to be made by the wireless network and provides much richer information to be made available on the wireless management platform.

This foray in to the Lync API was described as Aruba's move in the to brave new world of SDN: the application providing information for the network fabric to provision the resources required for an application. Exciting stuff!!! It certainly sounds like a good strategic move for both organisations. but I wonder if an open, standards-based API would be a better way to go long term (...imagine an unique API for every different application)? This (SDN) isn't an area of expertise for me, so please excuse any comments which seem mis-guided and please attribute them to my technical ignorance :)

Finally

Finally, I have to say thanks to Aruba, Microsoft and Gestalt IT for providing such open access to this event. The information presented was both valuable and fascinating. 

The event itself was very well organised (as you might expect from those Tech Field Day boys), with a great deal of both vendor material (from Aruba/Microsoft), together with the opportunity for some challenging questions from vendor-neutral folks as well. I think this open-forum approach really shows that Aruba is ready to listen, as well as very generously share, which really raises my opinion of them significantly (...not that it was low before, :) I've had no previous dealings with Aruba) .

I believe that Aruba are also going to make some of the material available from the presentations, in the form of videos and some of the slide decks - I particularly look forward to the recommended Lync QOS settings that were shared :)  I also strongly recommend that you review some of the great material that Aruba have made available about 802.11ac and their products.

This has been another very interesting and exciting chapter in the unfolding 802.11ac - thanks to Aruba, Microsoft & Gestalt IT.

References

Popular posts from this blog

The 5GHz “Problem” For Wi-Fi Networks: DFS

-
Image
Wi-Fi networking provides us with 2 bands for the operation of wireless LAN networks: the 2.4Ghz band and the 5GHz band. The 2.4GHz band has a reputation of being something of a “sewer” of a band, due to its limited number of usable channels, the number of Wi-Fi devices already using the band, and the high levels of non-Wi-Fi interference that it experiences. Many wireless LAN professionals will generally advise that you put your “important stuff” on the 5GHz band whenever possible. 5GHz has far more channels available, a corresponding lower number of devices per channel, and generally suffers much lower non-Wi-Fi interference. However, beneath the headline of “2.4Ghz = bad, 5Ghz = good”, there lurks a shadowy figure that can be troublesome if you’re not aware of its potential impact: DFS. Background Wi-Fi networks operate in areas of RF spectrum that require no licence to operate. This is in contrast to many other areas of the radio spectrum that generally require some form of (p...
Read more

What Are Sticky Clients?

-
Image
One term you'll often hear banded about when talking with Wi-Fi professionals is "sticky clients". I thought it might be worth spending a few moments exploring what is meant by "sticky clients", why they are generally considered to be a bad thing in Wi-Fi networks and some approaches to mitigate them. Background Many folks dealing with Wi-Fi networks often talk about the "sticky" characteristics of wireless clients when discussing client roaming within a W-iFi network. In an ideal world, we'd like to have access points providing ubiquitous coverage across our desired area providing high-quality, consistent client coverage where-ever we go. In this wonderful land of rainbows and unicorns, our clients would gracefully roam from AP to AP, detecting and associating with their closest AP throughout the coverage area to ensure their best connection speed at all times. Unfortunately, the real world doesn’t quite reflect this roaming-client...
Read more

Microsoft NPS as a RADIUS Server for WiFi Networks: SSID Filtering

-
Image
The Microsoft Network Policy Server (NPS) is often used as a  RADIUS server for WiFi networks. It can provide authentication and authorization services for devices and users on a wireless network in a Windows Active Directory environment. In this article we look at how we can use NPS to provide authentication for WiFi users across a number of SSIDs. We have previously discussed how to authenticate groups of users using the same SSID and then assign them to a VLAN that is appropriate to their security authorization. However, there may still be instances where two or more SSIDs are in-use on a wireless network and we would like to base policy decisions on the SSID that the authentication request is being generated from. As an example, if we consider a school, perhaps we would like students to only be able to authenticate if they connected to the SSID: "Student_Net". Similarly,  staff should only be able to connect using the SSID: "Staff_Net". This would ...
Read more