Graphic: Comparing Wireless Technology Range and Data Rates

This graphic helps visualize the different use-cases for various wireless technologies by comparing range and data rates.

A few notes:

• LTE could be included in the same area as WiMax, and could probably be re-named "4G".
• Wi-Fi will soon approach Gigabit speeds with 802.11ac and 802.11ad and would shift upward in the graphic.

Cheers,
Andrew

Kineto Smart Wi-Fi Calling on T-Mobile

This week I'm in New York City for Interop and had a chance to catch up with Steven Shaw with Kineto Wireless. Kineto developed the Smart Wi-Fi calling application which enables smartphone users to automatically use Wi-Fi network connections for both voice and SMS/MMS. Wi-Fi calling can provide superior indoor coverage and quality where cellular carriers typically struggle. In the United States, T-Mobile is the only carrier offering integration for Wi-Fi calling at this time.

T-Mobile subscribers must add the "Free Wi-Fi Calling" service to their rate plan, which is no additional charge since May of this year. Previously, the Wi-Fi calling still counted against plan minutes.

The Smart Wi-Fi application relies on Unlicensed Mobile Access (UMA) technology, which is based on the 3GPP (international GSM mobile standards body) Generic Access Network (GAN) standard. This is an extension of the GSM standard and is not available with CDMA networks such as Sprint and Verizon in the U.S. Of the two GSM networks only T-Mobile provides support for UMA today. However, with AT&T heavily investing in Wi-Fi hotspots through the Wayport acquisition and footprint expansion, it will be interesting to see if they become more receptive to Wi-Fi calling in the future. Additionally, Verizon and Sprint are unlikely to be receptive to this technology once they migrate to LTE, as both companies are pursuing other IP-based calling protocols instead of GAN and are looking to protect their average revenue per user (ARPU). Both companies have also declined to pursue Wi-Fi data offload to this point, but cellular network capacity issues may reach a critical level in the coming years prompting a change in direction out of necessity. Only time will tell.

Wi-Fi calling works by having the smartphone create a secure connection to the mobile network gateway by authenticating using EAP-SIM and establishing an IPSec VPN tunnel over the Wi-Fi network. The mobile network gateway presents itself to the mobile core as any other radio network controller, which turns the Wi-Fi or public IP network into another radio access network (RAN) similar to cellular towers. This also enables the full suite of mobile services to be available over the Wi-Fi network to ensure service parity and consistency of user experience.

Smart Wi-Fi Calling Routes Calls Over Any Wi-Fi Connection

T-Mobile users purchasing supported smartphones do not need to download the Smart Wi-Fi application, it comes pre-installed by the carrier (it's not available in the Android Market). Support for Smart Wi-Fi calling varies by model, so be sure to check out the list of supported Android phones on the Kineto website. Wi-Fi calling is enabled on the smartphone by default, but users can disable the service if desired by changing a single configuration setting within the application. A small blue callout bubble icon appears in the notification bar in the upper left corner when Wi-Fi calling is available. During an active Wi-Fi call the icon turns green.

The Kineto Smart Wi-Fi calling is enabled by default,
and provides easy configuration for users

Kineto has also optimized integration with Android to disable the 3G radio when Wi-Fi calling is active in order to maintain long-lasting battery life on the smartphone. There is really no need for both radios to be active at the same time since Wi-Fi now handles all voice and data services. This is a smart feature by Kineto, since smartphone battery life can be a deal-breaker for most consumers. One drawback to the consumer solution with T-Mobile is that once a call is placed or received it cannot be switched between the cellular network and Wi-Fi network with the Android Smart WiFi application. This is different than T-Mobile's enterprise UMA implementations on Blackberry and Nokia devices which allow in-call handover between cellular and Wi-Fi networks.

Kineto provided me with an HTC Sensation on loan for a few weeks to evaluate the service. Overall, I found the experience to be extremely intuitive and simple for users. Voice quality over Wi-Fi was excellent, although that could be highly variable depending on the performance of the Wi-Fi network the user is attached to. Voice calls only require around 80 Kbits of bandwidth over Wi-Fi, so it should work adequately over most public hotspot networks. I trialed the service over multiple Wi-Fi networks, including my home, enterprise, coffee shop (Caribou), and an AT&T hotspot, and never experienced any call quality issues. In fact, compared to T-Mobile's cellular coverage, call quality was actually better over Wi-Fi in most cases!

There are multiple benefits of this solution to consumers. First, Wi-Fi calling improves coverage reception in most indoor locations by leveraging a high-quality Wi-Fi signal at the micro-cell level rather than relying on poor penetration from the outdoor macro-cell carrier network. Second, when users offload calls to Wi-Fi they don't count against their bundled plan minutes on T-Mobile and can help consumers reduce costly overage fees on limited minute plans or save money by switching from an unlimited plan. Third, individuals that travel internationally can eliminate expensive roaming charges. Finally, a side benefit is increased incentive for users to connect to Wi-Fi in general, resulting in a (typically) faster data connection for browsing the web, watching videos, or checking up on Facebook posts.

On the enterprise side, Wi-Fi calling can help reduce overall cellular plan expenses across the organization by leveraging investment in corporate Wi-Fi networks already in place. Many teleworkers also work out of locations with public Wi-Fi frequently, such as coffee shops, cafes, and bookstores. In addition, Wi-Fi calling can help enterprises avoid the expense of in-building cellular coverage enhancement with cellular repeaters.

I caught up with Steven Shaw from Kineto Wireless at Interop, NY 2011 and asked him a few questions about Smart Wi-Fi.



Revolution or Evolution? - Andrew's Take
Wi-Fi calling is a clear benefit for both consumers and enterprises. It offers improved indoor coverage utilizing Wi-Fi networks, reduces minute plan usage and expenses, offers cheap international calling, and the implementation by Kineto is seamless and intuitive. There is really no reason not to use this service if you are T-Mobile subscriber in the U.S. Kineto also has a large presence in Europe and predominantly GSM cellular markets.

It's disappointing that U.S. based carriers other than T-Mobile have been unresponsive to this service to-date. I'm not sure Wi-Fi calling is a compelling enough service for users to switch carriers today. But with mobile data demands only increasing and the emergence of Hotspot 2.0 roaming between macro cellular networks and micro Wi-Fi networks, Wi-Fi offload strategies will become more predominant. This provides opportunities for carriers to improve indoor coverage by leveraging existing private network infrastructures. Whether this will materialize is yet to be seen. One thing is for sure, the technology exists today and it's an issue of business development and market approach by the carriers holding this service back. Perhaps pressure from over-the-top voice and SMS services like Google Voice, Skype, and Facetime will compel the carriers to keep pace.

For more information:
- Kineto Wireless
- Smart Wi-Fi powered by UMA
- Wi-Fi Calling Overview and Smartphones Supported
- Kineto Case Study - Enterprise Benefits of Wi-Fi Calling
- T-Mobile Wi-Fi Calling Support Document

Cheers,
Andrew

Full Disclosure - Kineto Wireless provided an HTC Sensation smartphone and pre-paid T-Mobile SIM card on loan for review of their Smart Wi-Fi application and service. However, all opinions are purely my own and I was not otherwise compensated for this review.

Cisco H-REAP Local Authentication Improvements

A while back I wrote about Cisco H-REAP, how it works, and some considerations and feature limitations.

As a follow-up, I'd like to briefly cover some recent changes in how H-REAP access points perform client authentication, specifically with the H-REAP Local Authentication features since this topic is confusing for most engineers (in-part because of the name).

H-REAP Local Authentication in code version 7.0.116.0 encompasses three distinct options for authentication of clients when "connected" to a WLC or "standalone".

Backup RADIUS Servers (AP as NAS)
This is the long-standing H-REAP feature that allows the AP to source RADIUS authentication to external 'backup' RADIUS servers when in standalone mode and the WLC in unreachable. In this scenario, the AP is the authenticator which forwards requests to the authentication server (RADIUS server). The authentication server must have the APs defined as a NAS.

This permits the APs to accept new clients and successfully complete authentication without reliance on the WLC. This is really a high availability feature for the WLAN to prevent an outage if one or multiple controllers fail.

Define the H-REAP backup RADIUS servers from the H-REAP Group:

H-REAP Backup RADIUS Servers

Update - Based on feedback in the comments, it should be pointed out that the AP and RADIUS server must use the same shared secret as configured on the wireless LAN controller. The AP inherits the RADIUS server definition and configuration from the controller, and it cannot be configured separately. This applies to both AP as a NAS situations.

Local Authentication (AP as RADIUS)
This feature allows the H-REAP access point to assume the role of both the authenticator and the authentication server (RADIUS server). The AP is required to have local users defined and only support a few EAP types, notably EAP-FAST and LEAP.

This feature is what most engineers describe this feature as meaning, without knowledge of the 3rd option below. Having locally defined users and restricted EAP types makes this option not all that attractive for most organizations, but there are some who have obviously requested it from Cisco. It beats static pre-shared keys for security, but creates administrative burden on network administrators to define and manage local users on the H-REAP APs.

Many organizations already have user accounts stored in corporate directory systems such as Active Directory, and definition of users in an alternate database is not preferred or allowed. That said, this feature doesn't make a lot of sense for user accounts tied to real people since corporate security policies usually dictate that passwords are rotated regularly and support personnel don't have access to those passwords, preventing them from being replicated on H-REAP APs. However, it may make sense for non-user IDs attached to embedded devices such as IP phones, Vocera badges, or handheld scanners.

Enable H-REAP Local Authentication (AP as RADIUS) in the H-REAP Group:

Enable H-REAP Local Authentication by the AP

Additionally, define local users and configure EAP-FAST and LEAP:

H-REAP Local Auth User Definition

Local Authentication (AP as NAS)
Historically, when the H-REAP AP was connected to a WLC, all authentication flowed through the controller. In code version 7.0.116.0 this changed. Now administrators can configure H-REAP APs to source client authentication and bypass the WLC, even in connected mode. This is beneficial when the AP is logically closer to the RADIUS server than the WLC and should source authentication itself to improve performance. A remote site that contains both H-REAP APs and a RADIUS server, with a centralized controller across the WAN is one example.

Enable H-REAP Local Authentication (AP as NAS) in each WLAN:

Enable H-REAP Local Authentication in the WLAN

When this option is enabled, the AP sends client authentication requests to servers in this order:

1. WLAN AAA Servers
2. H-REAP Group Backup RADIUS Servers (primary/secondary)
3. AP Local Authentication (local users on the AP)

One other quick note is that the H-REAP APs also support RADIUS fallback. So if a primary RADIUS server fails and subsequently comes back online, the AP will recognize this and begin sending client authentications back to the preferred server.

Hopefully this clarifies some of these new features that aid both high availability and performance.

Cheers,
Andrew

Microsoft Lync QoS

This week I'm back to my favorite topic, quality of service. Engineers across multiple teams at my current employer have been working on a project to enable wireless VoIP using softphones running Microsoft Lync on both Windows 7 and XP. This project has provided an opportunity to review how our organization handles multi-function wireless devices and network performance, with particular focus on quality of service mechanisms.

We've found some interesting things...

Wireless QoS - Not a "One-Size Fits All" Policy (Anymore)
Since Wi-Fi is a shared medium with control distributed to all active nodes in the system, proper network arbitration and performance is heavily dependent on client behavior. When dealing with QoS using 802.11e/WMM, this means accurate application traffic marking and queuing by client devices themselves. 802.11e prescribes 8 user priorities and 4 priority queues to provide a base level of differentiated services for traffic (you can read more about this in my Wireless QoS 5-part series).

Many wireless LAN vendors have only provided basic support for wireless QoS by reading the QoS values within frames and queuing traffic for downstream transmission to clients. Some vendors have begun going beyond basics to provide customers with a feature called "Airtime Fairness", which are proprietary extensions to ensure more in-depth control of clients by the infrastructure. I particularly like how Devin Akin at Aerohive highlights that this feature is really manipulation of the environment to suit a specific policy, whether it be equitable between clients or not. However, these are still mainly downlink traffic mechanisms, and the uplink flow is still controlled by the client. (There are some exceptions to this that involve infrastructure vendors monkeying with client TCP windows, acknowledgments, etc., but let's not get into that now.)

Device Convergence
A Swiss-Army Knife of Capabilities

Traditionally, vendors have implemented QoS on a per-SSID basis. This worked decent once-upon-a-time when all devices had only a single purpose in life. It was fairly easy for administrators to segment data-only devices such as laptops from voice-capable devices such as IP phones. No problem. Everything in the SSID gets slapped with a QoS template and we're done.

But what happens now when we have veritable Swiss-Army devices that perform multiple functions. What SSID do we put those in? How do we differentiate network performance and QoS based on application flows rather than device or SSID?

The answer is that wireless clients and the network must both have more intelligence to handle dynamic QoS requirements. Device convergence and the use of multi-purpose devices eliminates the ability to effectively use static 1:1 QoS policies tied to wireless SSIDs. We need something better!

Microsoft Lync QoS - A Case Study
Microsoft Lync is a software platform for unified communications providing data, voice, and video collaboration on Windows workstations. Many organizations are exploring device convergence to expand capabilities available to all employees while controlling capital and recurring costs.

As part of our lab verification of Lync prior to production deployment, we tested Wi-Fi quality of service integration. Microsoft Windows Vista, Windows 7, and Server 2008 platforms support policy-based QoS, while older Windows XP systems only support two service levels with the QoS Packet Scheduler. I'll focus on Windows 7 workstations with the more robust policy-based QoS capabilities. We setup an Active Directory GPO to classify and mark all voice traffic coming from Lync with a DSCP value of 46 (expedited forwarding), which is a general best-practice on IP-based networks (see RFC 3246 section 2.7) and conforms with Cisco's QoS Baseline recommendations.

The resulting traffic analysis verified that Lync correctly marked DSCP in the packets, but we also noticed that the layer 2 Class of Service (CoS) marking for 802.11e/WMM is set to 5. We expected to see 6, since the 802.11-2007 standard clearly states in table 9-1 that user priorities 6 and 7 are reserved for voice, while 4 and 5 are reserved for video (note that the Wikipedia entry on 802.11e contains incorrect data). This is distinctly in conflict with the 802.1p CoS values for wired LANs (using the revised 802.1Q-2005 values) which places voice traffic in priority 5.

Microsoft Lync marks layer 2 CoS values based on mapping 
IP Precedence values (3 most-significant bits in IP ToS header field)

Moreover, the mappings between layer 2 and layer 3 markings are distinctly different between vendors. Microsoft maps layer 2 CoS values, whether 802.1p or 802.11e, to the same set of layer 3 values based on IP Precedence (not DSCP) and does not differentiate between wired and wireless networks. Mappings in the opposite direction (DSCP to layer 2) also rely on only the IP Precedence values and not on the full DSCP codepoint. Therefore, a DSCP value of 46 is translated as an IP Precedence of 5 and a layer 2 priority of 5. Cisco, on the other hand, maps values differently for wired and wireless networks (see Table 2-7) to accommodate the variations between standards.

Differences in layer 2 Class of Service (CoS) values between IEEE standards
and layer 2 to layer 3 mapping implementations by vendors create complexity

The root of the issue is two-fold. First, the 802.1p and 802.11e QoS values are clearly in conflict. This makes accurate QoS implementation difficult to achieve because variations need to be dealt with correctly by each and every solution implementation. This introduces plenty of room for error. Second, Microsoft's QoS implementation in Windows maps DSCP to layer 2 CoS based on legacy IP Precedence values. It does not differentiate between wired and wireless network connections and adjust markings appropriately.

Network-Wide Ramifications
The standard practice of marking voice with DSCP 46 will result in the improper classification, marking and queuing of the traffic throughout the network.

First, wireless client transmisions (upstream) by the Windows workstations will get placed into the video queue and will not receive the appropriate contention window values. This will reduce the statistical advantage that voice frames receive for transmission over the air and could impact voice latency and jitter, especially in video rich networks. As video adoption in the enterprise increases, especially with increasing mobile device usage, this could have serious effects on voice quality.

Second, many wireless network infrastructure vendors to do not provide the ability to inspect and re-classify traffic and are forced to trust the client markings. For example, the Cisco Unified Wireless Network simply enforces a maximum QoS value for each SSID that clients cannot exceed. If the SSID is configured for Platinum QoS, then no maximum can be exceeded and traffic will be translated based on the client marking. The CAPWAP tunnel will map the client's layer 2 value of 5 (video) to a DSCP value of 34 for the outer tunnel IP header. Once the traffic is de-encapsulated by the controller, it applies an 802.1p value of 4 based on the CAPWAP packet DSCP value 34 mapped back to a layer 2 wired value, while leaving the client packet's original DSCP value of 46 untouched. Given the best practice of configuring switches to trust DSCP from CAPWAP APs and trust CoS from controllers, this traffic will be mishandled by intermediate switches and routers as well. In fact, the default Cisco switch behavior (when QoS is enabled) is for DSCP transparency to be disabled, and will result in the trusted layer 2 value coming from the WLC overriding the original client DSCP marking and being re-written to 32 based on the default switch CoS-to-DSCP mapping.

Third, advanced wireless voice control features will be ineffective and broken since the voice traffic is not properly identified within the voice queue. This includes TSPEC, call admission control (CAC), traffic bandwidth reservation, expedited bandwidth requests to facilitate emergency 911 calls, and voice stream metrics collection and reporting. Many of these features are only available to traffic streams within the voice queue. Additionally, off-channel scanning used by RRM and rogue detection are configured to defer if traffic in user priorities 4, 5, or 6 have been received in the last 100ms. If this policy has been changed to only defer for priority 6 traffic it could negatively impact Lync traffic in priority 5 by increasing network re-transmissions and network latency.

Finally, WAN bandwidth across the network could be negatively impacted. Typically, network administrators will design WAN circuits to reserve bandwidth for a specific amount of voice calls (based on Erlang calculations) as well as enforce a per-call bandwidth limitation based concurrent call volume. Since the voice calls will not be placed into the voice queue, no traffic admission or policing can occur. Should the environment grow to a point where concurrent voice calls exceeds the design, then WAN bandwidth may not be sufficient to handle the additional calls but will not be able to restrict call admission, resulting in poor voice performance.

Let's also not forget the risk of human error somewhere down the road. Assuming documentation is in proper order, policy accommodations have been made throughout the network, and engineer transitions include adequate knowledge transfer, a clear risk still exists that future changes will inadvertently affect voice traffic since it isn't supposed to be within the video queue.

Integrating Lync Into a Broader Network Architecture
Our networks aren't created in a vacuum; it's a shared resource and engineers must design networks to handle varying capabilities and demands of all connected endpoints and traffic flows. So, what options are available to mitigate this issue and effectively handle Microsoft Lync voice traffic on a converged wireless network?

We could ignore the problem and apply the standard voice QoS value of DSCP 46 (EF) in our Windows policy. This will result in accurate marking and traffic handling for wired clients, but suffers the ramifications previously described for wireless clients and broader network resource impacts. Hardly an optimal solution.

Instead, consider applying a non-standard DSCP marking. Using this approach we use policy-based QoS on Windows platforms to mark voice traffic as DSCP 48 (CS6), which allows it to be mapped to the correct wireless layer 2 CoS value of 6 and be queued correctly for transmission by the client.

The problem is that this DSCP value is reserved for Internetwork Control traffic by most networking vendors (including Cisco). Network administrators will need to ensure that wired and wireless integration is configured correctly, otherwise incorrect classification could propogate throughout the network for these traffic flows. For Cisco wireless networks this means that switch ports should be configured to trust DSCP from APs and CoS from controllers. This trust coupled with the Cisco wireless mappings between CoS and DSCP ensure that the correct DSCP value of 46 (EF) will be used both in the CAPWAP tunnel and re-written by the switch (based on WLC CoS trust) on the client packet once forwarded upstream out of the controller.

If using another wireless vendor, engineers should review the QoS capabilities of the solution and integration options to ensure accurate handling of this traffic. For example, many vendors support robust inspection and classification of traffic flows to match configured QoS policy directly in the access point. In these instances, configure APs to identify voice traffic and apply QoS based on defined policy.

This configuration will also cause incorrect markings when the workstations are connected to a wired network, which is still a likely occurrence for laptops in most environments. Network administrators should ensure that switches are configured to strip the client QoS markings on switch ports throughout the network, which is standard practice. This way the switch will ignore the client markings and re-apply QoS policy using traffic inspection techniques. Ethernet switching largely eliminates medium contention concerns on wired networks, so having an incorrect policy on the first-hop upstream is not a large concern.

I prefer to implement this solution. With proper end-to-end network QoS implemented, accurate traffic handling can be accomplished on both wired and wireless networks.

Revolution or Evolution? - Andrew's Take
Clearly something went wrong with standards-based QoS development. Divergent layer 2 QoS definitions exist from the IEEE standards. Furthermore, no standard mappings exist between layer 2 and layer 3 QoS values, as evidenced by differences in vendor implementations.

As mobile device convergence proliferates and wired and wireless networks continue to become more closely integrated, consistent end-to-end QoS policy definition and traffic handling will be critical in supporting increasing network demands.

Microsoft Lync highlights these challenges. Increasingly, organizations are looking for converged solutions to provide improved business capabilities and service. And many client platforms won't have as robust control or policy definition options as Windows. How will your organization handle voice, video and data over iOS, Android, Blackberry, Windows Phone 7, and other platforms?

Cheers,
Andrew


Additional Links for Microsoft Lync and Windows QoS:

• Microsoft TechNet Quality of Service Content Section
• Microsoft Lync Quality of Service (QoS) Overview
• Microsoft Policy-Based Quality of Service
• Overview of Policy-Based QoS
• Creating a Client Quality of Service (QoS) Policy
• QoS Packet Scheduler (Windows Server 2003 and Windows XP)
• Enabling Quality of Service on Windows Server 2003 and Windows XP
• MSDN Blog - Introduction to 802.1p
• MSDN Blog - WiFi QoS Support in Windows Vista: WMM
• MSDN Blog - WiFi QoS Support in Windows Vista: WMM part 2 (contains 802.1p to DSCP mappings)
• MSDN Blog - Using Policy-Based QoS to Enable and Manage WMM in Enterprise Wireless Deployments
• MSDN Blog - Content Tagged with QoS
• Integrated Research whitepaper titled "QoS: The Missing Link" on the Webtorials website (free registration required)

Adopting Wireless Client Testing & Verification Procedures

As many professionals in the industry know, Wi-Fi clients cause the majority of issues on wireless networks. This is due to the ambiguity of implementation details for many features within the IEEE 802.11 specification. With the current 802.11-2007 standard clocking in at over 1,200 pages in length and the 802.11n amendment adding another 500+ pages, it's already tremendously complex. Yet it still does not define how some functions should be implemented in shipping product. This leads to varying interpretations of the standard, inconsistent behavior between different devices (and often-time between devices of the same model / part number), and at worst product incompatibilities. The Wi-Fi Alliance does an adequate job ensuring basic compatibility. However, inconsistencies between infrastructure and client devices still exist and can cause major headaches for corporate IT departments burdened with supporting the mobile device influx as well as standard corporate owned devices.

Organizations should adopt internal testing and verification procedures that certify all changes to infrastructure and client devices in a lab prior to rollout in production environments. These procedures and testing ensure that most wireless connectivity and performance issues will be identified in a lab environment and corrected prior to rollout. This will greatly improve network stability and reduce downtime.

In addition, since Wi-Fi utilizes a shared medium, understanding the capabilities and limitations of your client device base will enable network engineers and architects to design a solid solution that meets ALL client requirements in their environment. Unfortunately, this also means that the wireless network typically must be designed to support the least common denominator as far as client devices are concerned. Knowing device limitations will enable an organization to identify, prioritize, and appropriately budget for device replacement as well as integrate new requirements into device sourcing events.

Consider including the following types of tests in your procedures:

1. Client Basic Association Test - assess the ability of the client device to establish a connection to the network using the applicable authentication and encryption methods approved for use.
2. Radio Coverage Association Test - assess the ability of the device to re-establish a network connection after moving outside of the AP coverage area then back into the coverage area.
3. Radio Strength Test - assess the RF signal strength and signal quality of the client device.
4. Radio Interference Test - verify the ability of a device to remain associated to an AP during periods of interference at varying levels.
5. Radio Scan Test - assess the ability for the device to scan only a subset of channels to improve active scanning performance and reduce latency during association and roaming.
6. Radio Poor Signal Test - assess the ability for the client device to establish a network connection in an area with poor coverage to determine effective receive sensitivity and coverage boundary.
7. Radio Roaming Analysis - assess the performance of the device when roaming between multiple APs using the applicable authentication and encryption methods approved for use. Hint - breakdown the roaming into several sections to determine where delays may be occurring (probing, association, EAP, EAPoL key). Also look for anomolies including de-authentication or dis-associations.
8. DHCP Roaming Analysis - assess the client DHCP behavior and performance during network roaming (including DHCP renewal behavior).
9. Application Behavior Testing - verify the ability for the application to function correctly under the given scenario, sometimes also referred to as User Acceptance Testing (UAT). This can also identify performance problems due to incorrect application design or development (typically due to strict application timers designed to work over low-latency wired local area networks, not wireless networks).
10. Network WAN Latency Test - assess the client and application performance given varying WAN latency (if the RADIUS or application server is remote across a WAN).
11. Network WAN Load Test - assess the client and application performance given varying WAN load (if the RADIUS or application server is remote across a WAN).
12. Network WLAN Load Test - assess the client and application performance with varying levels of WLAN clients on the same access point or channel.
13. Network WLAN QoS Test - assess the client and application support for QoS traffic classification, marking, and prioritization over the air using 802.11e and IP DSCP.
14. Battery Life Test - assess the battery life of mobile devices under various load conditions, usage frequency, and battery ages.
15. Radio Power Save Operation - assess the interoperability and performance of the device with various power save modes of operation (PS Polling, U-APSD, PS Multi-Poll).
16. Device Sleep / Hibernation / Screen Lock Behavior - assess the behavior of the device after being placed into a sleep, hibernate, or screen lock state and brought back awake.

Document each test sceanario and include a detailed description of the test case, devices to be tested, test setup, test execution steps, results to be measured, measurement methods, expected outcomes (success criteria), and include a logical diagram of the test environment and execution.

Also, document the procedures in a clear, concise, and detailed fashion to ensure process repeatability. This will allow the organization to establish consistent testing processes, establish netwok and device performance baselines, and allow comparison of new results to historical results. Repeatable and well-documented procedures will also allow process handover to new staff members as roles and responsibilities change, as well as aid in network troubleshooting should the procedure need to executed by an untrained employee at a remote site in an emergency.

Upon execution of each test case, the following data points should recorded, analyzed, and included in test reports (may vary between tests):

• Infrastructure hardware models, software  versions and configurations deployed (perhaps grouped into configuration "releases" similar to common software development practices)
• Client device operating system version, supplicant used, software versions, and driver versions
• Functional test scenario observation of results
• Multi-Channel packet capture and analysis
• Automated protocol analysis (includes high level wireless statistics, such as retransmissions, channel utilization, etc.)
• Spectrum analysis

Execution and analysis of these tests will require investment in advanced professional-grade wireless LAN tools, specifically for packet capture, protocol analysis, and spectrum analysis.

Organizations should invoke these testing procedures in the following circumstances:

• Wi-Fi infrastructure code upgrades
• Wi-Fi infrastructure configuration changes
• Device software upgrades (OS, driver, or supplicant)
• New device deployments
• New application deployments on wireless clients

A dedicated lab environment should be created to mimic the production environment as closely as possible. This will also allow testing to be performed in an isolated environment which cannot impact the production network.

Revolution or Evolution? - Andrew's Take
Defining, implementing, and regularly executing wireless network and device verification procedures can be time consuming but can drastically improve network uptime and performance. The initial cost of time, labor, and investment in professional tools will quickly be recouped through the elimination of support incidents, subsequent resource utilization and loss of business. As wireless networks continue to grow more complex and client diversity explodes with the "i-Everything" and BYOD trends, investing time up-front in client testing and verification will reap dividends with improved network stability and should reduce support expenses in the long-run. It will also make your network users (and management) happier!

Cheers,
Andrew


Other Posts You Might Like:

• Using Wireshark Coloring Rules to Enhance Wi-Fi Protocol Analysis
• Wireshark WLAN Traffic Statistics and IO Graphs
• Understanding Wi-Fi Carrier Sense
• Wireless QoS (5-Part Series)
• [QoS] It's Tricky, Tricky, Tricky, Tricky...
• Limit SSIDs & Data Rates to Maintain Network Performance

Custom Wireless Access Point Mounts

Quite often the topic of access point mounting options comes up when discussing Wi-Fi solutions and exchanging best practices and experiences with professional peers.

It is not surprising that many professionals in the industry find the vendor supplied AP mounting brackets insufficient, and search for mounting solutions that can better meet their needs in a cost-effective manner. The standard access point mounting brackets bundled by many vendors are usually ineffective for common deployments. By common deployments I mean cubicles, offices, carpeted areas, or generally open and accessible spaces that require omni-directional RF coverage.

Standard Vendor Wall and
Ceiling Mount Brackets - bleh!

Vendors typically provide either wall-plate or drop-ceiling frame brackets. Wall-plate brackets are easy to deploy, but having APs visible in the workplace is usually not very aestethically pleasing (let's face it, most enterprise grade APs are ugly, but some have been getting better) and in many environments wall mounted APs also cannot provide an optimal RF coverage or capacity for the physical space (think of large open areas without interior walls and exterior walls too distant to effectively cover the center of area). Drop-ceiling frame brackets also typically leave ugly APs exposed and also can be a pain to install, having to cut out holes in existing ceiling tiles to run Ethernet cables through to the APs. This may not be of big concern for a small company, but deployments of any significant size will quickly realize the inefficiencies involved when installing hundreds or thousands of access points in this manner. Additionally, standard vendor brackets are usually a pain to install with tegular ceiling tiles where the tiles are not flush with the framing structure, but reveal below the edge.

Hence the need for most wireless installers to seek alternative mounting options.

Off-the-Shelf Mounts
A quick search on the Internet will yield hundreds of solutions for off the shelf 3rd party mounts for most wireless manufacturers and AP models. Although much more aesthetically pleasing, these solutions are typically extremely expensive. Mounts that cost upwards of $200-$300 each are not uncommon and can significantly increase the solution cost. Consider enterprise grade access points that can be acquired for $300-$600 each (depending on vendor, list price, discount structure, customer contract details, etc.), those 3rd party mounts could very well increase a project budget by 30-70%. That's a significant additional expense for to an organization without adding much value.

Note - certain exceptions do exist where specific access point mounting features are required and can drive value for the organization, such as NEMA enclosures for deployment in harsh environments or secured locking enclosures in high risk environments.

Sample 3rd Party Wireless AP Mount - Nice, but Expensive!

Custom Mounts - A Better Solution for Many Applications
Rather than use the vendor supplied mounts or expensive 3rd party mounts, consider creating or sourcing custom mounts that fit your specific needs. For instance, custom drop ceiling mounts can be sourced from a plastics manufacturer that look aesthetically pleasing, cost significantly less (especially when ordered in bulk), and can provide optimal coverage for common spaces requiring omni-directional access point antennas. Here is an example:

Cisco 3502i Custom CELTEC PVC Foam Drop-Ceiling Mount

You can see that the 2'x2' custom mount looks very similar to the 3rd party mount. However, instead of being manufactured out of powder-coated steel or aluminum, this is made with CELTEC PVC Foam. This plastic is highly durable and can easily support the weight and load of most wireless access points.

This mount was made specifically for a Cisco 3502i wireless access point. Partnership with a plastics company was quick and resulted in a fairly simple, yet elegant design. The mount itself is only 1/4" thick allowing for bulk packaging and shipment. The plastic has a custom machined hole that is beveled to match the contour of the front face of the access point. On the reverse side, a neoprene sleeve secures the access point in place to prevent shifting and eliminate risk of injury during installation and maintenance. The neoprene sleeve has a specially designed hole at the center for heat dissipation and stretches for AP installation. A second hole has been engineered to provide easy routing of cables to the access point.

Pricing for the custom mounts is much more reasonable, and can range from $25-$40 each depending on the volume ordered, and typically reduces related expense down to 4-13% of project budget.

Revolution or Evolution? - Andrew's Take
Custom access point mounts can fit a variety of needs in a cost-effective and aestethically pleasing manner, and allow deployment flexibility to meet RF design requirements. Minimal up-front engineering effort is required when partnering with a plastics manufacturer. Prior to purchasing wireless access points, determine the mounting requirements and leave the mounting kit that most vendors supply out of the purchase. They're usually not worth it anyways. Avoid 3rd party mounts unless you can source them at a reasonable price, and don't get caught paying for extra features (such as swing doors and locking mechanisms) that are not required for your environment. CELTEC PVC Foam mounts provide durable and quality mounts for most deployments. Find a plastics manufacturer that can deliver on your design requirements and are responsive to customer needs.

Cheers,
Andrew

Cisco Live! 2011 Wireless & Security Recap, and an Apple Rumor

Last week at Cisco Live! 2011 I attended several sessions related to wireless LAN products and would like to provide a review of the major technical announcements that I took away from these presentations. Due to the overwhelming amount of technical content provided over the course of the 6 days, I won't be providing detailed recaps of each session. However, there were several major announcements that could impact customer roadmaps that I would like to discuss.

You can also read my article on value of live events on professional development and networking on the Cisco Mobility Blog.

CCIE Wireless Version 2 - On Sunday, several of my peers attended a CCIE-W techtorial which discussed the changes to expect in v2 of the written and lab exams. I did not attend this session, but you can find excellent recaps of the information presented by Jason Boyers (IPExpert), George Stefanick (my80211.com), and Blake Krone (Digital Lifestyle). You can also find my previous review of the v2 blueprint changes.

Some of the interesting facts that I caught from other included the relative scarcity of CCIE Wireless engineers - only 45 total worldwide, and only 27 outside of Cisco. Small numbers indeed!

ISE / TrustSec Overview - Several salient details of the new ISE platform include:

• ISE bundles multiple systems under one product, including ACS, NAC Manager, NAC Server, NAC Profiler, NAC Collector, and NAC Guest Server. These roles can all be installed on a single ISE instance or split between multiple ISE instances.
• ISE is out of band and provides central policy definition and enforcement.
• ISE focused on determing both device and user identity for complete contextual policy definition and enforcement. It supports a myriad of EAP types, similar to the Cisco ACS product.
• ISE also provides policy management for non-802.1X capable clients via MAC Auth Bypass (MAB) and/or web-authentication, which is important for wired network security. 802.1X timeouts will need to be tuned much shorter than the default of 90 seconds to allow MAC Auth Bypass and DHCP processes for non-802.1X clients to continue un-interupted, prior to device profiling and policy enforcement. Pre-auth ACLs can also be defined to limit access until device profiling and policy assignment can occur (PXE boot is one scenario to consider).
• Flex-Auth aims to allow a single port-configuration to accommodate client devices of all types (802.1X, MAB, web-auth) to ease switch port management. Failover behavior betweent authentication types can be defined to meet customer requirements.
• ISE supports device profiling using many different methods, including 802.1X authentication parameters, MAC address OUI lookups, DHCP options via SPAN port / IP helper / proxy, reverse DNS lookups, HTTP user-agent via SPAN port / captive web portal on ISE, NetFlow v5/v9, and SNMP queries & traps.
• Device profiling is hierarchical, can define generic categories then drill into more detailed profiles if desired to apply more specific policies. (Example: IP Phones > Cisco IP Phones > Cisco 7960 Series).
• Device profiles can be created using combinations of gathered information from the previous bullet point to provide a more educated interpretation of what the device is. This should help reduce false positives and false negatives as well as make it difficult for someone to spoof multiple device capabilities.
• ISE fully supports RADIUS Change of Authorization (COA) which allows dynamic policy changes in the middle of client sessions if the environment changes. Previously, only support for initial policy assignment upon the initial network access attempt was supported. COA can include client disconnection, re-authentication, port bouncing, or port shutdown. Note that the WLCs support COA as of version 7.0.116.0 code.
• It supports authorization & policy management via dynamic VLAN assignment, dynamic ACL assignment, downloadable ACLs, and Security Group ACLs.
• ISE provides a new security paradigm based on Security Group Access (SGA). SGA relies on Security Group Tagging (SGT) which is hardware ASIC dependent. SGTs are assigned based on successful RADIUS authentication and attribute assignment back to the network access device.
• Older equipment such as the 3750 switches do not support full Security Group Tagging. Such platforms will rely on a software upgrade to support the SGT eXchange Protocol (SXP) which will relay IP address to SGT mappings to neighboring equipment which do support SGT. This allows end-to-end network-wide support for the Security Group Access model and a migration path without forklifting existing equipment. Note that the wireless LAN controllers will support SXP with code version 7.0.116.0 and later. For a full list of hardware and software compatibility, see the Cisco TrustSec SGA Solution Config Guide.
• SGA simplifies network security policy enforcment with ingress SGA tagging, and egress SGA enforcement based on both the source and destination SGT combinations. This reduces the need to distribute policy definition throughout the entire network, simply enforce security for central servers and data stores once at egress. See the solution guide linked above for more information.
• It currently does Not Support TACACS+, only RADIUS (focused on client authentication, not admin).
• ISE logging is much more detailed than the current ACS product, providing more information to troubleshoot authentication and policy management for clients.
• ISE and NCS management platforms are tightly integrated. The GUI looks very similar to provide consistency, and client reporting in NCS provides ISE specific authentication and profiling information for easier monitoring and troubleshooting.

See my previous posts for a review of Wireless Network Segmentation Options and Dynamic VLAN Assignment.

WLC Code Support - The legacy WiSM-1 and 4400 series controllers will not be supported on code versions 7.2 and later. The latest supported code version will be 7.0. Customers should plan accordingly and prepare for hardware upgrades in the near future if they intent on deploying new features. Note that sotware maintenance for bug fixes and security patches will continue on the 4400 platform until 2014 according to the EoL notice.

ELM aWIPS Limited HW Support - Enhanced Local Mode (ELM) WIPS will only be supported on 802.11n access points. I am not sure if this is due to hardware limitations or not, but this is a huge issue for existing customers looking to support this feature. ELM was designed for highly distributed environments where the cost of an overlay solution was prohibitive. In lieu of that target market, I would have to say that Cisco seems unwise to limit support to new 11n access points. I would venture that most retail or other distributed environments already have deployed wireless network, many with older 11a/b/g hardware. The whole value proposition of ELM to reduce hardware deployment costs gets thrown out the window with this move and really invites customers to evaluate the entire WIPS market which includes other overlay solutions. This can only be a bad move for Cisco!

RRM Modifications - Significant changes to the RRM algorithm have been made between WLC versions 4.2 to 7.0. These include fixes to eliminate pinning (the worst APs cannot improve and prevent other APs in the same RF group from being changed) and cascading (propagation of a single channel change across all APs in the RF group). For example, an AP channel change event can only cause subsequent changes to first-hop APs which are direct RF neighbors of the original AP modified. RRM is preferred over static channel and power assignments becuase most RF environments are dynamic and change over time. Cisco recommends that customers who had issues on older code versions re-evaluate the use of RRM in their environments with these enhancements.

RRM First-Hop Neighbors (purple) Are Allowed
To Change Channels, But Not 2nd-Hop Neighbors (blue)

Also, most RF designs using RRM should be designed to allow APs to operate at medium power levels (values 3-5) so that RRM can adjust power levels up or down as necessary. If the network is designed with minimal overlap and APs operate at maximum power level 1 all the time, then RRM can adjust power higher to compensate for coverage holes or AP failures.

BandSelect Recommendations In-Flux - The historical official recommendation from Cisco documentation, TAC, TMEs and other support personnel has been to disable BandSelect on voice WLANs to prevent roaming delays. Since BandSelect delays probe responses on the 2.4GHz radio, it can cause roaming delays that may impact performance of an active voice call. However, we heard from a few sources during multiple presentations that voice engineers within Cisco may have validated minimal impact to voice calls and recommending customers to turn it on the voice WLANs. No official change has been made to formal recommendations at this point, but may be an interesting topic to watch for changes in the future.

Cisco Stadium Wi-Fi - The new 3500p access point and 25137NP (36⁰ spot-beam dual-polarization antenna) provide focused coverage for stadium seating sections. This solution also incorporates changes to the RRM algorithm and Wi-Fi Clear-Channel Assessment (CCA) specific to supporting a high-density environment. Read more about it here.

Cisco Narrow Beamwidth Antenna Focuses on
Individual Stadium Seating Sections

Layer 3 Roaming Enhancement - New in code version 7.0.116.0 is support for layer 3 client roaming when clients have static IP addresses configured.

Redundant Controller Licensing - Cisco WNBU (Wireless Networking Business Unit) has heard customer requests for backup controller licensing instead of having to purchase redundant units with full licensing for the intended AP capacity required. However, this change has not yet been committed to by WNBU. If you are a Cisco wireless customer and deploy N+1 or N+N redundancy, you should contact your Cisco account team to formally request s this change and throw added pressure on the pile!

Multiple LAG Groups on WLCs - Cisco WNBU is also considering adding support for multiple link aggregation (LAG) groups on the controllers. This would allow more flexible deployment in scenarios where controllers need to connect to separate physical networks, most common in DMZ anchor controller deployments I would imagine. For instance one LAG group connects to physical switches that lead into the core and another LAG group leads to a different set of physical switches that lead to the Internet. Currently, the only way to do this is to not use LAG at all and use a single physical interface for each side of the connection. This limits throughput to 1Gbps maximum. Multiple LAG support is not yet committed to by WNBU, so once again, call your account team to formally request support if it's important to you as a customer.

Rumor Apple will Support Fast Roaming in iOS 5 - There was also a very interesting rumor that was brought up in Wednesday's "Design and Deployment of Enterprise WLANs" that Apple may support 802.11r Fast BSS Transition (fast roaming) in it's upcoming release of iOS5. If this turns out to be true it will be a major improvement for support of Apple mobile devices including the iPhone, iPod Touch, and iPad in an enterprise environment. In a corporate setting these devices are much more likely to be leveraged as a converged devices supporting voice and video integration with corporate PBXs and video collaboration systems which require fast roaming for uninterrupted sessions.

Support for 802.11r should also officially come in Cisco WLC code version 7.2, although hooks have been in the WLC since the first 7.0 train release of 7.0.98.0.

Cheers,
Andrew

Cisco Live! Brings Virtual Communities Together

Last week Cisco Live! 2011 took place in Las Vegas, NV. This year was my first time attending the conference, and I am a bit amazed at my experiences looking back on the event now that it is over. In addition to the deep technical content the conference is best known for, I found more valuable benefits are afforded to attendees willing to take a more active role in the technical community.

Arguably, the most valuable aspect of the conference is the opportunity for professional development through interaction with influential members of the industry, both internal and external to Cisco. Professional networking provides a foundation for growth and success by drawing on the energy of a collective group of friends and associates who share similar ambitions and have a drive to be successful, enabling the group to move forward as a whole. Building communities within the industry is when the magic starts to happen. Joining these communities can provide access to shared knowledge, creation of new and exciting opportunities, leveraging of broader connections throughout the community, and promotion of valuable content, products, or services created by trusted members within the community.

Many of these communities begin as virtual communities, built on social media platforms such as Twitter, LinkedIn, Facebook, and the rapidly growing Google+. These platforms enable greater access to members within the community, but must be used appropriately to be effective. Individuals trying to join the community must provide value to the larger collective and interaction must be genuine. A quote from a widely successful writer and blogger comes to mind…

Networking is always important when it’s real, and it’s always a useless distraction when it’s fake. – Seth Godin

Industry events, such as the Cisco Live! conference, bring the virtual community together allowing attendees to build on existing relations formed online and expand on them by providing more personal interaction, helping to form more meaningful relationships.

The conference provides organized formal opportunities for attendees to have direct access to internal Cisco resources who present many of the sessions, the ability to meet Cisco Press authors, interaction with experts one-on-one, and casual discussion during planned social events such as one of the many welcome receptions or the customer appreciation event.

The event also provides a great forum for informal virtual communities to self-organize and enhance the value of the event by networking with peers, discussing session content, exchanging unique perspectives, and gathering insight from experts across numerous technical fields. A large group of networkers that are active on Twitter organized ad-hoc ‘tweetups’ to do just that. Having been a member of this virtual community for some time, the opportunity to meet many of them face to face was invaluable and solidifies my trust and reliance on them, and on the broader community, as a valuable resource in my professional network. The ability to interact in more relaxed social settings after conference activities concluded during many of the days provided deeper friendship among many, and I would like to think that we have formed more lasting relationships among one another.

Our Twitter Networkers Group at Cisco Live! 2011

In fact, our group was so active in the event that we garnered the attention of a few conference organizers and even established an un-official tweetup table outside the registration area. We coined the table “Tom’s Corner” due to the most active organizer among us (Tom is in the Collaboration User’s Group, which is probably not a coincidence). By Wednesday night we had even garnered an exclusive tweetup section at the Customer Appreciation Event!

The use of social media during the event also allowed attendees to provide live session updates to the broader virtual community and incorporate real-time discussion and feedback during sessions Q&A periods. The feedback that I received was one of genuine gratitude for providing content to the broader community and the ability for others to be involved in the event even if they could not attend.  In addition, social interaction between attendees at the conference was frequent, allowing live discussions within many sessions as well as access to content in alternate sessions occurring at the same time.

Cisco Live! provides a wealth of opportunities for individuals to grow their professional networks through personal interaction and to make networking ‘real’. Join the community and we’ll see you next year!

Cheers,

Andrew vonNagy 

Note - This post originally appeared on the Cisco Blog on Mobility. Thank you to Scott Simkin for providing the opportunity to share my experiences with the broader Cisco audience!

Measuring RF Antenna Gain in dB-MEG

Typical Dipole Antenna Radiation Pattern

Isn't it fun when you think you know the ins-and-outs of a technology, then run across something that fundamentally has you scratching your head in confusion? You've been working with a technology for quite some time and you think you've seen it all, or at-least heard about it all if you haven't had the need to work with specific pieces.

In Wi-Fi we learn a lot about how decibels measure relative, not absolute, power output in relation to some other reference point. We have dBi (isotropic radiator), dBm (1-milliWatt), dBd (standard dipole antenna), etc. These are known quantities, and most Wi-Fi professionals worth a lick can run circles around antenna azimuth or elevation patterns and specifications using these units of measurement. We get them, we know them, we are "comfortable" with them.

Then something comes along and throws us off our game, and pushes us to question our own basic understanding of the universe of Wi-Fi (Hey, that's kinda catchy: "universe of Wi-Fi". I might have to start using that phrase). Such was the case last week for me. It all revolves around the db-MEG. "dB-what?" That was my first reaction too!

Vehicle Mounted
Mobile Device

Let me provide a little bit of background. The retail organization where I work owns and operates dozens of Distribution Centers (warehouses) that accept bulk product, process, and ship it out to hundreds of stores apiece. These warehouses have yard hostlers, essentially trailer cabs that ferry semi-trailers to/from parked positions and dock doors. These cabs are outfitted with rugged vehicle mounted mobile devices with a cable lead for an external antenna mounted on the roof of the cab. Since the mobile device in question only provides a single external antenna lead, signal reception (or lack thereof) becomes an important consideration given the lack of antenna diversity. Now, these devices have been around for a while and mobile device selection and ownership are owned by a partner team, not the Wireless Engineering team directly. Additionally, they were deployed before I joined the team.

Laird Phantom Antennas

The vehicle mounted mobile devices in the yard were installed with Antenex / Laird "Phantom" antennas (we also have more of these mobile devices inside the warehouse, but they are in operation with the built-in omni-directional antennas). These antennas are manufactured for use in mobile vehicular environments, typically in urban environments with high amounts of RF signal reflection, refraction, diffraction, and scattering. Additionally, these antennas don't use typical units of measurement, they use a new gain specification called the dB-MEG. It appears that this technology has actually been around for a while, referencing an IEEE paper from 1990. The vendor (Antenex / Laird) claims that these Phantom antennas provide "a radiation pattern tailored to the mobile environment" by tuning the directivity and polarity of the antenna.

The dB-MEG is defined as follows:

Decibels Mean Effective Gain is used by one  manufacturer. To establish the Mean Effective Gain for their antenna, received power is first measured and averaged using a ¼ wave whip (0 dBi) in a real mobile or reflective environment.

The whip is then replaced with their antenna, and again measured in the same environment.

The MEG gain is then the ratio of the two received powers. On average their antenna receives twice the power of the ¼ wave whip in a mobile or reflective environment. Alternatively said, their antenna has 3dBi Mean Effective Gain.

Here are sample specifications from one such antenna that we have in-use in our environment:

Laird TRAB24/49003P Sample Antenna Specifications

Intermittently, we have problems with these devices dropping connection during roaming events. After we verified adequate coverage, ruled out interference, ran active tests and debugged the connection, I am ultimately questioning adequate signal reception by the client. Given two things really leads me to this conclusion: 1) The mobile device does not support diversity with external antennas, and 2) these Phantom antennas have lower gain than dipoles (when measured in dBi) and not quite omni-directional beamwidths. I can understand why our partner team chose these models, they are seemingly a good fit for mobile vehicles. However, their intended application in urban environments with high signal reflectivity and multipath is not even close to the same use-case as our warehouse shipping and receiving yards in rural American locations with vast wide-open spaces, fluctuations in trailer density in the parking lot, and minimal multipath. I am questioning whether the antenna radiation patterns (shown above) are causing the intermittent signal drop-out.

The problem isn't licked yet, but running across something new like dB-MEG presents a previously unknown variable to consider. I wasn't aware of this measurement unit in the market, and wouldn't have been unless I had run across this issue with an already deployed product in our environment or worked on an urban outdoor mobile vehicular project of some sort.

I'm still learning about these Phantom antennas, and have many more questions. However, based on these specifications and our performance issues, I'm not sold on their application in our environment.

I've added dB-MEG into my arsenal of Wi-Fi acronyms, even if it's categorized in the "nice to know, but not really useful" section.

Cheers,
Andrew

WLAN Vendor Selection Criteria - What Matters Most?

Last month I ran a short 1-question survey, asking readers to rate the importance of various factors when selecting a wireless LAN vendor. I received 95 responses, which was pretty good turn-out for an informal survey on my little corner of the blogosphere. Thank you to all that responded to the survey!

The survey results are in, and here are the findings.

Note - This was NOT a scientific survey. These results only indicate the importance of criteria based on the survey respondents.

Survey Question:
What are the most important factors that influence wireless LAN vendor selection?

Rating Levels:

1. Not Considered
2. Low
3. Average
4. High
5. Critical

Survey Results
Survey responses revealed the following average ratings for each factor:

Survey Results - Importance of Various Factors When Selecting a WLAN Vendor
(click to enlarge)

Detailed response breakdown:

Survey Results - Complete Response Breakdown
(Click to Enlarge)

The Most Important Criteria

• Product Quality Assurance & Stability scored the highest, with an average rating of 4.24. Additionally, this factor received the most "Critical" rating accounting for 40% of all responses for this item. Clearly customers want bug-free code and network stability from their vendor of choice. Vendors should not lose focus on product quality in order to speed time-to-market, especially if that means sacrificing development, code review, QA testing, or customer trials (alpha / beta).
  
  
• Vendor Technical Expertise also scored really high, with an average rating of 4.16. This factor received over 83% of responses for either "High" or "Critical" importance. This points to a strong need to leverage professional services for WLAN installations. Given the relative complexity of deploying high-performing wireless networks, the growing demand for Wi-Fi networks, and the explosive growth of mobile devices, this is not surprising. Many customers are not equipped with the resources to handle these projects and need to lean on vendors, partners, and managed service providers for technical Wi-Fi expertise. Expect continued substantial compound annual growth rate (CAGR) for professional services in the industry.
  
  
• Solution Scalability is important for customers as networks grow. Based on the response breakout, solution scalability appears to be applicable to more customers than either Product Quality Assurance & Stability or Vendor Technical Expertise, having over 88% of responses rated "High" or "Critical". However, customers concerned about QA/stability and vendor expertise rated those as "Critical" more often than scalability. There is no doubt that the WLAN industry is seeing tremendous growth in product shipments since the release of 802.11n, and despite the recent economic recession. Customers are expanding networks, adding coverage and capacity, and require solutions that can handle increasingly large network deployments effectively.
  
  
• Support Response Time & Escalation are also highly important, with over 50% of responses rated as "High" and 27% as "Critical". Customers require qualified vendor support and rapid escalation and remediation of issues to minimize network disruptions. Just as many organizations are relying on outside expertise for professional services during network design and installation phases, similar expertise is required for post-sales support and incident response.
  
  
• Other notable important items include:
  
  
• Vendors should provide easy access to Product Documentation. Vendors should not require current support contracts, or make customers create an account on the website to access documentation. By doing this, vendors make it difficult for customers to be self-sufficient from a support perspective, place roadblocks and barriers in front of valuable training resources, increase vendor support costs, and limit publicly available information that potential future customers could use to become more familiar with your products. Vendors only hurt their own existing customers and future product sales by doing this (or they have something to hide that they don't want competitors to see, which they will eventually anyways).
  
  
• A solid Management Platform will include features to monitor, configure, report and alert on all features within the network products. Vendors need to place appropriate resources into network management systems to ensure customers are able to effectively use and manage their products without requiring advanced technical skill sets. Often times, organizations utilize experts for initial deployment, then turn over day-to-day management and support to less experienced or less specialized teams (provisioning, help desk, etc.). Vendors should enable these teams to mange the network in an easy-to-use fashion that is intuitive and requires a minimal learning curve.
  
  
• Hardware and Software Maintenance Structures are important for customers as they continue to get more sophisticated in TCO analysis and look for ways to minimize Operational Expenses (OpEx) over the lifetime of the product deployment. Vendors will need to offer solid value propositions for hardware and software warranty policies or face significant push-back from customers. This has already been reflected in the industry as multiple vendors are now decoupling hardware from software maintenance contracts, offering customers the flexibility to choose an equipment sparing and support strategy that meets their needs. Expect increased scrutiny of software maintenance structures (including licensing) as customers look to simplify financial analysis and avoid getting nickel and dimed for table-stakes features or support that may be deemed unnecessary.
  
  
• Wireless network Architecture Approaches are gaining increasing visibility within the industry, as small vendors hammer the drum on controller-less architectures and big vendors continue to develop distributed solutions to handle increasing traffic loads with 802.11n, 802.11ac, and 802.11ad which are quickly complicating current controller-based models. Increased importance on this topic is expected as network loads and utilization continue to increase and as industry analysts continue to highlight the diverging approaches within the industry. This will be a make-or-break decision point for many customers, especially customers with highly distributed environments.

Least Important Criteria

• Maintaining a Single Vendor Network was the least important factor for most respondents, with 10% rating it "Not Considered" and 26% rating it "Low". However, a small contingent of respondents do factor this into their decision process with 26% rating it "High". Based on these two opposing viewpoints this is a divisive subject with large variability between customers. Clearly there are two camps of thought on this topic. This leads me to believe that the single vendor mantra may hold more weight when specific requirements must be met or in environments where a clear value proposition exists. This value could stem from many different points, including process efficiencies, integration capabilities, reduced duplication of effort to support multiple products with varying capabilities, or reduced workload training and supporting a complex environment, etc. However, for customers without a clear requirement or value proposition, this factor holds little weight.
  
  
• Vendor Market Share and OEM Relationships are not critical to the vendor selection decision. This highlights a great opportunity for smaller vendors to increase customer base through both overall market expansion as well as in direct competitive sourcing events. This also highlights the highly competitive nature of the Wi-Fi market today and the need for continuous improvement by all vendors to stay relevant.

Other Trends and Implications

First, vendor RF and security feature differentiation are still a significant factors in the WLAN industry. However, customers appear more willing to accept vendor roadmaps for feature parity rather than jumping to a competitor to acquire a single innovative feature. Customers are evaluating complete solutions, and barring a "killer" feature, will give vendors time to develop comparable features. With most vendors utilizing merchant silicon, time to market for most features are now relatively quick based on software development timelines. Vendors that can differentiate based on fundamental architecture approaches or hardware capabilities will stand to gain more competitive advantage than vendors focusing on software feature innovation.

Second, advanced wireless services such as Real-Time Location Services (RTLS), Guest Wi-Fi (hotspots, partner access), and wireless intrusion prevention services (WIPS) are of increasing relevance to customers as IT departments move beyond providing basic network connectivity and evolve into more of a service organization. Vendors must either dedicate resources to develop integrated value-add wireless services and capabilities, or establish over-the-top capabilities through strong ties with 3rd party best-of-breed solutions including strong systems integration to present a unified and cohesive platform for the customer.

Finally, the need for quality Wi-Fi training has never been more apparent. Heavy reliance by many organizations on external professional services highlights the demand for qualified Wi-Fi expertise and an insufficient number of experts available in the industry. If you're looking for quality training for yourself or your staff, check out my Wi-Fi Training Resources page.

Revolution or Evolution? - Andrew's Take
Although most vendor announcements, press releases, and industry analysis focuses on the latest wireless features, many customers still make decisions based on fundamental "critical factors" that directly impact their ability to conduct business. Vendors should ensure that innovation does not come at the cost of stability, and should focus heavily on professional services as customers require help to deploy next-generation wireless networks. This is a time of tremendous growth, competition, and innovation within the Wi-Fi industry. Technical Wi-Fi skill sets are in high demand, and the industry collectively needs more qualified experts to meet this demand. When the global economy stumbled through the recession, Wi-Fi kept going relatively strong. As the economy slowly emerges, this industry is set to explode! Small vendors will be growing rapidly, trying to sell customers on different architectural approaches and feature innovation. Large vendors will be expanding customer bases through established sales channels and selling advanced professional services. Customers will be buying, buying, buying, like crazy.

Customers - do you have well-defined requirements?
Vendors - do you have an appropriate market strategy to sell customers on your solutions?

I welcome reader feedback and thoughts? Do these results match your expectations? Are any important criteria missing that you would consider for vendor selection?

Cheers,
Andrew