Apple iOS Fast Roaming with Aerohive Wi-Fi APs

Well folks, after what seems like an eternity, true standards-based Wi-Fi fast roaming is really here! I blogged back in December that Apple iOS version 6.01 added support for fast roaming with 802.11r and 802.11k. And WLAN infrastructure vendors have added support as well, with Aerohive 6.0 and Cisco 7.2 code releases.

Recently, I had the opportunity to test this functionality out on an iPhone 5 and an iPad mini with an Aerohive WLAN. I'd like to share my results with you... and I can tell you that you won't be disappointed! How do 8.5ms roams sound?!

Apple iPad Fast Roaming (1) and Aerohive AP Neighbor Report (2)

As you can see, the iPad completes the roam in 8.5ms, the time it takes to complete the 802.11 authentication and reassociation; no full 802.1X authentication, RADIUS TLS session resumption, or even 4-way handshake are required! This is the result of support for the Wi-Fi Alliance Voice-Enterprise certification on both the WLAN and client. In the tests that were captured, the WLAN was configured for WPA2-Enterprise with 802.1X authentication and dynamic keying. The initial client association resulted in a full 802.1X authentication with the RADIUS server, followed by fast roams as shown above.

Roaming with 802.11r (Fast BSS Transition) is noticeably faster than other proprietary fast-roaming methods (OKC/PKC) and it's also faster than roaming on a Pre-Shared Key (PSK) WLAN. This is because the 4-Way Handshake exchange can be eliminated by embedding the key derivation material (ANonce, SNonce, MIC, and GTK) within the Fast Transition Information Element inside the 802.11 Authentication and Reassociation frames. There is also a Mobility Domain IE that comes into play to distinguish boundaries between different WLANs (since key material must be exchanged between APs on the backend, two separate WLANs cannot facilitate fast roaming).

Here's a look at the Fast Transition IE inside the Reassociation Response (frame 18) from the AP to the iPad:

802.11r Fast Transition Information Element

You may want to review my previous post on The Many Variations of Wi-Fi Roaming to compare the frame exchanges required with each roaming method, CWNP's whitepaper on Fast BSS Transition [PDF] and blogs (here and here) to understand the key hierarchy and exchange between the initial AP authenticator (PMK-R0) and subsequent APs (PMK-R1).

Immediately after the fast roam completes, the Apple iPad submits a Neighbor Report Request within a Management Action frame. In essence, the client is requesting a list of all the neighbors from the AP in order to build a list for future roaming events. This report can be requested on-demand by the client and can help improve roam times by reducing or eliminating the need for the client station to actively scan off-channel. This way, the client has a list of nearby APs that is always up-to-date and can quickly move to another channel where it knows another AP is waiting.

Here is a look inside the Neighbor Report sent back to the iPad from the Aerohive AP (frame 21):

802.11k Neighbor Report

Unfortunately, Wireshark does not yet have a protocol dissector for 802.11k neighbor reports, so manual decoding must be performed. You can see that the Category Code is 5 (Radio Measurement) is used. Inside the tagged parameters lies the neighbor report details, which contains an element for each neighboring AP in the same WLAN and details about the AP such as it's BSSID and channel number which I have highlighted above. In this case, there is one neighboring AP with BSSID "08:ea:44:78:14:28" and it is operating on channel 161 (0xA1 in hexadecimal). Other information in the report includes AP's reachability, security policy (similar or different), and capabilities for spectrum management, quality of service, power save, block acknowledgements, and PHY type (802.11a/b/g/n).

There are three IEEE 802.11 amendments that come into play which are all bundled up in the Wi-Fi Alliance Voice-Enterprise certification.

Standards and Certification Recap
The core of fast roaming was drafted in the IEEE 802.11r amendment, defining "Fast BSS Transition"  or just Fast Transition (FT) for short. The name is derived because every individual AP radio cell is defined as a "Basic Service Set (BSS)" in the standard, and the amendment defines a method for client stations to transition (also called roaming) very fast between AP radios. It accomplishes this by defining a Mobility Domain comprised of a set of BSSs (APs) within the same Extended Service Set (ESS, otherwise known as an SSID) which have been validated. Validated APs must coordinate with each other to exchange client station details, including pairwise master key (PMK) encryption material, and perform pre-authentication of the client prior to the roam. This speeds the client roam by eliminating the need to re-authenticate the client through 802.1X/RADIUS or having to perform the 4-Way Handshake to derive pairwise transient key (PTK) encryption key material even in the case of a simple PSK network. The 802.11r amendement was ratified in 2008.

The IEEE 802.11k amendment on "Radio Resource Measurement" defines methods for information exchange about the RF environment between APs and client stations. The goal is to enable the client stations to understand the radio environment in which they exist so that they have more information to make correct decisions about roaming and performance. Stations can take radio measurements locally, request measurement by other stations, or have measurement requested of them and return the results. One interesting aspect for fast roaming is the Neighbor Report, where a client can request an AP to measure and report the neighboring APs which are available within the same Mobility Domain, including several pieces of operational information about each neighbor such as: BSSID, channel, security policy, and capabilities for QoS, APSD (power-save), BlockAck, spectrum management, and PHY type (802.11a/b/g/n). Some other reports available with 802.11k include: channel load, noise histogram, location configuration information, link measurement, and traffic stream measurements. The 802.11k amendment was ratified in 2008 as well.

The IEEE 802.11v amendment on "Wireless Network Management (WNM)" defines methods for stations to exchange information for the purpose of improving overall performance of the wireless network. Where 802.11k is concerned only with the radio environment, 802.11v expands it to include broader operational data surrounding existing network conditions allowing stations to be more cognizant of the topology and state of the network. There are a multitude of WNM services, the most interesting (for me, at least) is the BSS Transition Management capability, whereby an AP can request a client to roam to another AP for better performance or capacity. Some other services include: co-located interference, diagnostic reporting, directed multicast services, location services, multiple BSSID capability, proxy ARP, QoS traffic capability, and traffic filtering service, to name only a few. The 802.11v amendment was ratified in 2011.

Each of these amendments define numerous capabilities, of which I will only scratch the surface in this post to highlight a few. If you are interested in learning more about the services defined in each of the amendments, visit the IEEE Get Program website to download the 802.11-2012 standard, or search the web for PDF versions of each amendment.

Aerohive WLAN Configuration
Prior to being able to test and execute a fast transition (FT) roam, you need to configure the WLAN infrastructure to support the 11r/k/v features. In Aerohive HiveManager, navigate into the Configuration section and edit the SSID on which FT roaming should be supported. In the Advanced section of the SSID configuration you will see two sections, one for WMM and one for Voice Enterprise.

Aerohive Voice-Enterprise Configuration (IEEE 802.11r, k, v)

Upon checking the first check box for Voice Enterprise, you will be presented with the following notice, informing you that Voice-Enterprise requires 802.11rkv and WMM AC-Voice which will all be enabled automatically.

You may have also noticed the note which states 802.11r requires WPA2 key management. This is because 802.11r advertises FT support in-part through the Authentication and Key Management (AKM) suites in the Robust Security Network (RSN) Information Element, which was included in the 802.11i amendment and WPA2 certification program. Pre-standard WPA did not include the RSN IE and therefore cannot support fast transition. So make sure you're using WPA2 (with either 802.1X or PSK) on the SSID as well.

Save and upload this configuration to at-least two APs, which will then begin including the Mobility Domain IE, Fast Transition IE, and Radio Management capabilities in beacons and probe responses to advertise these capabilities to clients.

Note - no explicit configuration is required to enable Voice-Enterprise on Apple iOS devices. Simply run iOS 6.01 or later and join a Voice-Enterprise enabled WLAN.

Client Limitations
In addition, the RSN IE which advertises encryption ciphers and authentication and key management (AKM) methods in-use on the WLAN to clients now includes a new AKM type to advertise Fast Transition key management. Some existing client drivers have issues parsing the RSN IE with additional AKM and will fail to association to the WLAN - in fact, they won't even try. Until client drivers are updated by manufacturers to support this addition AKM type, they will be unable to join any SSID that has Voice-Enterprise (specifically 802.11r) enabled.

Therefore, it is recommended to create a separate SSID specifically for Fast Transition capable clients and migrate them over to the new SSID.

Final Thoughts
Wi-Fi roaming performance has been a painful sore spot on the industry for many years. Problems were initially obscured through the use of open or WEP encrypted networks where roaming was relatively fast due to the simple security models implemented. However, as security improved with 802.11i and WPA2-Enterprise, roaming performance became a glaring issue, often taking >500ms or worse! This impacted the usability of real-time applications on an enterprise WLAN, forcing many network administrators to rely on less-secure PSK security methods.

Some vendors responded with proprietary fast roaming methods such as CCKM, OKC, and PKC. However, this served to fragment the industry and support for these methods were spotty at best. The IEEE thankfully stepped in and ratified the 802.11r amendment in 2008, yet it has taken nearly 5 years since then for enough momentum to build to finally implement standards-based testing and certification of fast roaming through the Wi-Fi Alliance Voice-Enterprise certification program.

However, now that standards-based fast roaming is here, IT IS GLORIOUS! I applaud Apple for being an advocate for fast roaming and implementing it into their iOS platform, likely because their devices get blamed for poor performance all the time. I encourage other mobile device manufacturers to follow suit, especially if their devices are used with real-time voice or video applications.

Cheers,
Andrew

Unboxing Apps

When folders first came out on iOS I loved 'em. I thought it would help me organize all my apps and bring order to my digital chaos. And to a small extent it did, at first.

But I've found the more apps that I shove into folders, the less I use them. And i really only USE a handful of apps on a daily basis anyways.

So today I'm blowin' up them folders and unboxing apps!

Maybe just by seeing the app icons more readily I'll be spurred into using them more often. It feels so fresh and new already!

Here's what made the first-page cut on my phone:

Are Apple iPhones Misbehaving on Wi-Fi

The latest generation of mobile devices, including the Apple iPhone 4S, may be causing performance degradation on your Wi-Fi network, which could be reported as a Denial of Service (DoS) attack by WIPS (wireless intrusion prevention systems).

One of my blog readers contacted me about a disturbing finding he had and asked for my opinion (thanks Thanh). The finding in question was that the Apple iPhone, iPad, and other mobile devices based on the latest Broadcom chipsets are setting really long Duration values in the range of 10-14ms within Wi-Fi control frames (e.g. RTS/CTS-to-self). This essentially reserves the medium for the device to transmit without a collision. The problem is that this is an excessively long period of time for an 802.11n capable device, and through my packet analysis I have found that no large frame transmission is subsequently occurring. This indicates that a performance problem may exist with the devices, and may be reported as an NAV DoS attack on the network by WIPS systems.

I've also heard anecdotal reports of this being observed on HTC Google Nexus One, Apple iPad 2, iPhone 4, some RIM Blackberrys, and even on a Broadcom evaluation board. So, there is a distinct possibility that this issue lies in the Broadcom chipset used in these devices and is not isolated to Apple devices. However, I have only tested this on my personal iPhone 4S and cannot directly verify those observations. So this post only details what I have actual been able to test and observe directly.

I had a hard time believing this could be true, so I investigated myself. Sure enough, I found the behavior when I tested.

Apple iPhone 4S Large Duration Value

What you see in the figure above is that the iPhone transmits CTS-to-Self frames at regular intervals, around once every second, with an excessively large Duration value. This causes all other Wi-Fi clients to set the NAV (virtual carrier sense) to the specified Duration value and defer transmission. Essentially, my iPhone was causing a blockage of all traffic on my wireless network for 11ms at regular intervals. Definitely not good for performance.

Possible valid explanations for this behavior could be:

1) Frame aggregation with 802.11n. I did see the iPhone using frame aggregation in other instances and using an appropriate Duration value around 4ms in those cases. But I did not see frame aggregation being used after the 11ms Duration control frames.

2) The use of a Transmit Opportunity (TXOP) on a QoS enabled WLAN in order to transmit a burst of packets within a specific QoS traffic class. I double-checked the TXOP values advertised by my access point and they are using the 802.11 default values of 0ms (single frame only) for best effort and background queues, 3.008ms for the video queue, and 1.504ms for the voice queue, which are much lower than the 11ms observed value.

3) A really large frame transmitted at a really low data rate. This is possible if the iPhone needed to transmit a 1,384 byte or larger frame at 1 Mbps to get such a Duration value. But I have all 802.11b rates disabled on my AP and verified in the packet trace that the iPhone was using 24 - 65 Mbps almost all the time, with only a few frames at my lowest available data rate of 6 Mbps.

After analyzing my packet trace I can find no evidence of my iPhone transmitting any data frames immediately after the control frame containing the high Duration value. This essentially rules out all three possible explanations.

Other possible explanations would be a poor client roaming algorithm that wants to halt traffic while it goes off-channel to scan for other APs to which it could roam, or a poorly designed battery saving technique for mobile devices. However, I captured on all three non-overlapping 2.4GHz channels and found no evidence of my iPhone probing on other channels during that 11ms time period. And using this as a battery saving technique doesn't even make a whole lot of sense because clients can already notify the AP of it's power save mode and the AP will buffer traffic until it wakes up, or at worst case send broadcast traffic at the configured DTIM interval, which is usually 102ms which allows for a much longer  sleep period anyways. Regardless, the iPhone indicated that it was staying awake (in active mode) in the control frames, so it appears to have not been putting the radio to sleep.

Frankly, I have no answer to explain this behavior. I don't exactly know what is going on.

The effect on a home network is likely to be small, since 11ms out of every 1 second is only about 1% of available airtime. However, in a corporate environment where mobile devices are being introduced into the environment at a staggering rate, the compound effect could be a serious reduction in Wi-Fi network performance and capacity! Think of having 30 students in a single classroom all connected with their mobile devices, 200 in a university lecture hall, or 500 at a trade show or conference. This is increasingly likely as smartphone and mobile device penetration is over 50% in the U.S. and other countries already, and consumers are typically carrying 2-3 Wi-Fi enabled devices with them at all time. The worst-case result in these environments would be so much reserved airtime that almost no network capacity would be left for actual user traffic. Just what we need trying to support tons of mobile devices on enterprise networks, huh.

If I uncover more details, I will update this post accordingly.

Thanks,
Andrew vonNagy

Use an iPad or iPhone as a Mobile TFTP Server

As network engineers, through the course of our work we often find ourselves out in the field working at either a remote location or on an un-familiar network diagnosing and troubleshooting issues, performing maintenance, or deploying new equipment. Quite often, this also involves upgrading code on network equipment, backing up configurations, or when called in to save the day (called a MacGyver - thanks Tom for that flashback) sometimes we even have to restore configurations or download a bug-free version of code to fix an issue.

If we are MacGyver, then our Swiss-Army knife is the trusty old TFTP protocol. Sure, it can be slow. Yes, it can have trouble traversing firewalls due to dynamically negotiated transfer ports. But it is about as widespread in networking equipment as file transfer protocols can get. SCP or SFTP would be better, but frankly have not been widely implemented.

We also love using our mobile devices just as much as non-geeks! Tom also did a nice write-up on a terminal console cable solution for iPads that is now widely popular among engineers. Today, I would like to highlight another useful application for network management from an iPad.

TFTP Server ($3.99) (Developer's Website)

Now with Dropbox integration and large file size transfers (>32 MB)!
 Key features:
* Full TFTP Server
* Supports file size transfers >32MB
* Dropbox integration - upload and download files from Dropbox
* One-touch Dropbox file upload
* Block size > 512 bytes
* WiFi IP address refresh
* Full logging
* Standard "swipe" to delete files

From the description, a few features really stand out. First, it supports file sizes larger than 32 MB. This is an absolute requirement for working on modern networks. Any wireless engineer who has managed code images on a controller-based WLAN system can attest that equipment images are growing larger by the month due to the rapid expansion of feature sets and supported thin-AP platforms (which typically have AP code embedded in the controller image). Second, and this is the hook for me, full Dropbox support! Yep, cloud syncing of image files, configuration backups, licenses, SSL/TLS certificates, etc. for easy retrieval and upload to networking equipment. If there was one complaint that I have about tablets in general, it’s the lack of a file system. Well, Dropbox and other cloud services go a long way to make that a non-issue. But it requires every application to integrate with the service independently. Luckily for us, TFTP Server does. Third, it supports running in the background. This frees up the user to switch between apps and multi-task. This allows complete network management using only your mobile device; you can console into the equipment and host a TFTP server all at the same time without requiring two separate devices.

Okay, enough description about the app. Let’s start using it.

Once you’ve downloaded it from the app store and launch it, you will see the main screen:

It consists of a slider button to turn the TFTP server on or off, and handily displays your current wireless IP address (Wi-Fi only, no hosting over 3G/4G).

  

Then, there are 3 tabs that control the operation of the app:

1.       Log – displays the server log to monitor server status and TFTP file transfer progress.

2.       My Files – displays a list of the files available on the mobile device, which have been synched from the Dropbox account.

3.       Dropbox – controls Dropbox integration and selection of files to sync with the mobile device.

The first step in configuring the application is to ensure you also have the Dropbox app downloaded and signed into your account. Designate a folder as the TFTP root directory for hosting files.

Second, open the TFTP Server app and go to the Dropbox tab. Click the Settings button to configure the TFTP root directory and link it to your Dropbox account. From here you can also Upload all Files that have been uploaded to the mobile device TFTP server and store them back on Dropbox.

Click Done and go back to the Dropbox tab. A new Show Files button is now displayed. Clicking on it will now pull up the TFTP root directory on Dropbox and allow you to select files to sync with the local system. Select any files that you need to host from the mobile TFTP server, then click Done. The files will be pulled down to the iPad / iPhone.

Once the files have been pulled down, you will see them in the My Files tab.

Okay, now it’s time for an actual file transfer. From the main screen, ensure that you are connected to a Wi-Fi network and have a valid IP address. Then turn on the TFTP server.

In a separate app (or device), console or SSH into the network device and initiate the TFTP file transfer. Here, I used SecureCRT for simplicity of writing this post.

The file transfer starts, and is visible in the Log tab on the TFTP Server app.

The transfer from the mobile device is noticeably slower than hosting it using laptop or an actual server. But the trade-off which sacrifices a bit of speed for complete mobility is likely worth it for most situations, especially when out in the field and a TFTP server is not available, or is located across a high-latency WAN circuit.

You can see the file transfer completes successfully in the terminal:

Overall, the TFTP Server app works well, is bug-free from what I have seen, and allows me to use only my mobile device in many instances, making my shoulder bag a little bit lighter. My shoulder thanks you!

Revolution or Evolution? – Andrew’s Take

As a network engineer, being thrown into “enemy” territory and unfamiliar networks can sometimes leave us scrambling to perform the simplest of tasks. At the same time engineers, like everyone else, are looking for ways to “do more with less”. In our varied travels, this means many of us are looking for ways to be more productive while carrying less equipment around. Being highly mobile improves our productivity and takes some of the strain out of travel.

Using an iPad or iPhone for complete network management is getting closer to reality with applications like TFTP Server now available. It’s not all that glamorous, but hey, when is an engineer’s work really ever glamorous. The little things in our day-to-day work can make all the difference in getting the job done while keeping our stress levels to a minimum.

Having this app handy is one of those little things that makes our job easier. Hurrah to that!

Cheers,

Andrew

Disclaimer – I was provided a free copy of the TFTP Server app by the developer, but all reviews and conclusions are wholly my own and were not paid for consideration.

Bookmarklets for Mobile Devices

I read a lot of news and like to share a lot of it with friends, family, and professional networks using various services on the web. The easiest way for me to collect, consume, and distribute this content is through social media services such as Google Reader, Twitter, Facebook, and Email. 

I'm also always on the go, and it's increasingly rare that I can devote enough time during the week in front of a traditional computer or laptop to read all the news, information, and stay up to date as much as I want to. Therefore, it's an easy investment for me to own a smartphone to consume content whenever I have a minute or two of downtime. This makes information consumption much easier and fits better into my schedule. I also recently purchased a tablet to fill the intermediate gap when the screen size of a smartphone just isn't suitable for some content, but a tablet is still portable enough to carry with me most of the time. 

However, transitioning from a full web browser (Chrome is my preference) on a laptop, to a mobile browser (Safari on my iPhone/iPad), has caused some challenges. Normally, I find quite a bit of content that is shared by others through any one of the aforementioned services, which I want to subsequently re-share or post to my social networks. In Chrome, I use Bookmarklets to accomplish this task. Bookmarklets are simply small bookmarks comprised of javascript code that performs a specific function with the content in the current browser window. For instance, the Google Reader bookmarklet allows adding, sharing and note creation of items into your Google Reader feed.

Many of these bookmarklets are provided as links in webpages, allowing full browsers such as Chrome to easily drag and drop the link into the bookmark panel. However, mobile Safari does not allow direct bookmarking or copy/paste of these javascript links.

Therefore, I have copied out the javascript contents of these links in order to install these bookmarklets in mobile Safari. The process is fairly simple:

1. Copy the bookmarklet URL javascript contents from a desktop browser (or use my favorites listed below)
2. Email the contents to yourself
3. Open the email on your mobile device
4. Copy the javascript content from the email
5. Open mobile Safari
6. Create a new bookmark while on any page
7. Edit the bookmark, name it appropriate to the service, and paste in the javascript in the "Address" section

Now, when you're browsing any content that you want to share, click the appropriate bookmarklet from the bookmark menu and the service will prompt you to edit/send the item.

Here are some of my favorite bookmarklets:

Hootsuite Post

javascript:var d=document,w=window,f='http://hootsuite.com/twitter/bookmark-tool-v2?',l=d.location,e=encodeURIComponent,p='address='+e(l.href)+'&title='+e(d.title),u=f+p;a=function(){if(!w.open(u,'t','scrollbars=0,toolbar=0,location=0,resizable=0,status=0,width=550,height=330'))l.href=u;};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else a();void(0);

Hootsuite Post (launch iOS application)

javascript:location='owly://'+location;

Google Reader Note

javascript:var b=document.body;var GR________bookmarklet_domain='http://www.google.com';if(b&&!document.xmlVersion){void(z=document.createElement('script'));void(z.src='http://www.google.com/reader/ui/link-bookmarklet.js');void(b.appendChild(z));}else{}

Instapaper Note

javascript:function iprl5(){var d=document,z=d.createElement('scr'+'ipt'),b=d.body,l=d.location;try{if(!b)throw(0);d.title='(Saving...) '+d.title;z.setAttribute('src',l.protocol+'//www.instapaper.com/j/890WCIa1VUrN?u='+encodeURIComponent(l.href)+'&t='+(new Date().getTime()));b.appendChild(z);}catch(e){alert('Please wait until the page has loaded.');}}iprl5();void(0)

Facebook Post

javascript:var d=document,f='http://www.facebook.com/share',l=d.location,e=encodeURIComponent,p='.php?src=bm&v=4&i=1265501632&u='+e(l.href)+'&t='+e(d.title);1;try{if (!/^(.*\.)?facebook\.[^.]*$/.test(l.host))throw(0);share_internal_bookmarklet(p)}catch(z) {a=function() {if (!window.open(f+'r'+p,'sharer','toolbar=0,status=0,resizable=1,width=626,height=436'))l.href=f+p};if (/Firefox/.test(navigator.userAgent))setTimeout(a,0);else{a()}}void(0)

Gmail Message

javascript:popw='';Q='';x=document;y=window;if(x.selection) {Q=x.selection.createRange().text;} else if (y.getSelection) {Q=y.getSelection();} else if (x.getSelection) {Q=x.getSelection();}popw = y.open('https://mail.google.com/mail/?view=cm&fs=1&tf=1&to=&su=' + escape(document.title) + '&body=' + escape(Q) + escape('\n') + escape(location.href) + '&zx=RANDOMCRAP&shva=1&disablechatbrowsercheck=1&ui=1','gmailForm','scrollbars=yes,width=680,height=510,top=175,left=75,status=no,resizable=yes');if (!document.all) T = setTimeout('popw.focus()',50);void(0);

Cheers,

Andrew

A Look Ahead to Possible Wi-Fi Industry Trends in 2011

Many of the trends from the past year will carry over into 2011 and continue to impact the industry, while a few new developments are poised to radically alter the landscape. Here are my projections for some of the developments we should expect to see in the coming year.

1. Wireless as the Primary Enterprise Access Medium – spurred by large-scale adoption of 802.11n equipment, more organizations and employees will increasingly rely on Wi-Fi networks for the bulk of their work. Although a complete shift to Wi-Fi is unlikely except for a minority of organizations aggressively seeking expense reduction, most organizations will realize that the benefit of a scaled-down switching infrastructure, eliminating unused switch port capacity, and deploying greater capacity Wi-Fi networks to handle mobile workers.
   
   
2. Smart-AP Architectures Begin to Emerge from Market Leaders – just as 2010 saw established competitors challenge the common wireless controller architecture, market leaders will look to begin migrating to a more distributed architecture with smart APs. As industry experts continue to recognize that controller features can now cost-effectively be implemented in smart APs, market leaders will be forced to react and keep pace, or face continuing erosion of market share to innovative up-and-comers. However, the transition for large established equipment manufacturers will not be easy, having to support current customers with a deployed base of controllers as well as customers still running legacy autonomous access point architectures. Watch for product feature sets to begin migrating back into the smart APs in 2011, but don’t hold your breath for a viable large-scale controller-less solution, as ditching the controller will be tough given their wealth of feature that need to be migrated. Also, implementing coordination among smart APs will be limited to small groups of APs upon first release to ensure product stability. Watch for the large vendors to position these smart APs in parallel to existing controllers to prevent erosion and cannibalization of existing revenue streams, targeting smaller SMB/SOHO deployments for initial product releases while continuing to recommend controllers for larger installations.
   
   
3. Consumer Device Adoption in the Enterprise Becomes the Norm – enterprise Wi-Fi networks are a bit of an anomaly, having gained broad adoption in the consumer space long before enterprise. As such, Wi-Fi is viewed more as a utility by employees, who more commonly expect to connect any device to any network to get connected. Underscoring a major societal and cultural trend of the connected lifestyle, enterprises will be forced to support consumer-grade devices on corporate networks. This will present challenges for IT departments to provide secure and controlled access to corporate data. Mobile device management (MDM) solutions will increasingly be sought after to manage the great diversity in client platforms. Wireless network engineers will need to take care to architect solutions to alleviate poor consumer device performance and ensure mission-critical devices and applications achieve the required QoS and SLA required. Watch for organizations to take baby steps in support of these devices while they develop broader strategies for device funding, liability, and security compliance. Support may initially be limited to Internet and/or thin-client access to corporate applications and data, with broader access following strategy definition and procurement of management solution.
   
   
4. Mobile Commerce Leads to More Retail Hotspots – if 2010 was the year of mobile advertising, 2011 will be the year of mobile commerce and greater consumer interaction. Retailers are looking to keep pace in highly competitive markets and adjust to shifts in consumer behaviors, specifically targeting mobile commerce applications. Wi-Fi hotspots have long been a staple of cafés and bookshops, but will see increasingly broad adoptance among other retailers looking to provide a mechanism for customer engagement while in-store where they have the most influence at the product location. Wi-Fi will serve as a foundation for mobile commerce and marketing applications due to its pervasive presence in consumer smartphones and the lack of adequate 3G/4G cellular data network coverage within many brick-and-mortar facilities. Retailers will need to be careful to ensure the content is engaging, relevant, and provides a great customer experience. Watch for more hotspots to spring up throughout 2011.
   
   
5.  Emergence of Smart Meter, M2M, and Sensor Networks – wireless sensor networks have long been confined to the realm of university research and limited deployment mainly in the structural engineering field. However, this technology is maturing to the point where mass-market adoption is within the realm of possibility. Use-cases in the enterprise for smart buildings, energy efficiency, and better facilities monitoring and management coupled with commercial products for the consumer market with products to enable a connected home (thermostats, televisions, blu-ray players, home entertainment and set-top boxes, etc.) will bring smart meter, machine-to-machine (M2M), and sensor networks into the mainstream. Manufacturing costs are reaching low enough levels to allow product pricing to reach inflection points which could drive mass consumption by consumers. Enterprises, on the other hand, will be slower to adopt this technology due to investment in current systems, and deployment will likely be reliant on the rebound of the economy to spur new facility construction. Also watch for government funded economic stimulus projects to make increasing use of this technology. Sensor networks hold the potential to radically shift how Wi-Fi networks operate, shifting from human interaction networks to largely automated systems that require higher levels of stability and consistent network operation. Wi-Fi engineers should be able to proactively identify these shifts and manage network changes to provide greater availability and capacity.

What trends will you be watching for in 2011?

Cheers,

Andrew