Showing posts with label mobility. Show all posts
Showing posts with label mobility. Show all posts

Friday, October 25, 2013

Wi-Fi Alliance Voice-Enterprise Certification: Standardized Fast Secure Roaming


Two of the most important aspects of building a successful modern enterprise wireless LAN are enabling transparent user mobility across the network and strong security to protect sensitive corporate data. 

However, these two objectives have historically been difficult to achieve in tandem. A balancing act between mobility and security has caused an unpleasant trade-off for organizations due to the time-consuming processes that strong security methods require. On one hand, high performance mobility can be provided when relatively weak security is implemented with an Open or WPA2-Personal WLAN, but this leaves sensitive corporate data at higher risk of exposure. On the other hand, much stronger security can be implemented with WPA2-Enterprise, lowering the exposure risk of sensitive corporate data, but resulting in poor mobility performance due to the time-consuming 802.1X authentication process. Thus, the introduction of more secure Wi-Fi networks solved one problem (security) but created another (roaming performance).

The industry needed a high performance, yet secure, solution to this mobility problem. The answer lies with fast secure roaming. Pre-standard solutions, such as CCKM and OKC have been around for some time but have failed to realize widespread adoption, especially by client manufacturers. The Wi-Fi Alliance™ Voice-Enterprise certification program, introduced May 2012 and already appearing in major WLAN products, brings a standards-based fast roaming method to market, which serves to align infrastructure and client manufacturers on a common implementation method and provides the benefits of low-latency roaming performance while maintaining strong security with WPA2-Enterprise.

I dive deeper into the Voice-Enterprise certification program and implementation details of fast secure roaming in the new whitepaper, "Wi-Fi Alliance Voice-Enterprise Certification: Standardized Fast Secure Roaming" [PDF].

Whitepaper: Wi-Fi Alliance Voice-Enterprise Certification
(Click to Download)

Download this whitepaper to learn:
  • Challenges in providing both transparent user mobility and strong security
  • Requirements that products must pass to achieve Voice-Enterprise certification
  • Performance criteria that Voice-Enterprise products must achieve
  • Technical details of the Fast BSS Transition specification, based on IEEE 802.11r, for both controller-based and controllerless WLANs
  • Performance optimizations available with Radio Resource Measurement (802.11k) and Wireless Network Management (802.11v), both part of the Voice-Enterprise program
Cheers,

Wednesday, October 5, 2011

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.

Friday, April 29, 2011

Wi-Fi Article Round-Up: 2011/04/29

Here are a collection of Wi-Fi related articles that I have found useful, interesting, or enlightening. As always, for a complete list of articles check out my shared article feed from Google Reader.


My Stuff:
Industry Wi-Fi Articles:
Techie Wi-Fi Articles:
Other IT Related Articles:
Comic for the Week:
It's not "off-shoring", it's "best-shoring"...

Dilbert.com



Cheers (and happy reading),
Andrew

Thursday, October 28, 2010

Auto-Anchor Mobility Fundamentals

Having a fully redundant guest network architecture can be beneficial for service availability. Depending on business and operational requirements, many organizations use the guest architecture for purposes where traffic needs to be tunneled to a single point in the network, not necessarily just "guest" traffic in the traditional sense.

In a Cisco Unified wireless network deployment, this is accomplished with Auto-Anchor Mobility Tunneling by establishing Mobility peer relationships between internal production controllers and isolated controllers (typically in a bastion host or DMZ segment firewalled from the internal network). When using the auto-anchor mobility feature, these controllers do not need to have the same mobility group name because no layer 2 fast roaming or session state synchronization needs to occur between the controllers (layer 3 roaming is still performed to allow the IP address to be maintained by the client).


Typically, the DMZ anchor controllers are simply termination points within the isolated network segment and do not directly control any lightweight access points. This allows the DMZ anchor controllers to be smaller scale controllers, sized for bandwidth and throughput rather than AP licensing. Typically 4402-25 or 5508-25 controllers are used. Also, layer 2 roaming between APs on the controllers does not come into play.

Also, note that each production internal controller should have a mobility peer relationship with every other DMZ anchor controller to which it will send traffic. However, each DMZ anchor controller only needs mobility peers with each production internal controller, not with other DMZ anchors controllers.

Mobility communication between controllers occurs using their management interfaces, and uses the following protocols:

  • UDP 16,666 is used for Mobility control traffic between peers (Control Path)
  • IP Protocol 97 is used for Ethernet-in-IP traffic tunneling of client traffic (Data Path)

To setup the mobility peer relationship, navigate to the Controller > Mobility Management > Mobility Groups section. Add a new mobility group member by specifying the peer's management interface MAC address, IP address, and it's mobility group name (not the local one).


The status will initially show both the Control and Data paths down. Once communication is established, the status will show as "Up". Mobility peer connection establishment and keep-alive is performed at a periodic interval which defaults to every 10 seconds.

Note - The control and data paths may individually be shown as down if communication can be established using one protocol but not another. Check network ACLs or firewalls for traffic restrictions if this is the case.

To verify connectivity and peer kee-palive timers at any time, the following CLI commands may be useful:

  • mping peer-ip-address - used to test the Control Path between mobility peers
  • eping peer-ip-address - used to test the Data Path between mobility peers
  • show mobility summary - used to view mobility configuration and timers

Next, anchor the guest WLAN to multiple anchor controllers in the DMZ for round-robin client load balancing and redundancy. All mobility anchor controllers are used (active/active operation). This is accomplished from WLANs > WLAN Name Blue Arrow Drop-Down Button > Mobility Anchors.

On the production internal controller - specify one or more DMZ anchor controllers as the mobility anchors for the WLAN.



On the DMZ anchor controllers - specify its own IP address (local) as the mobility anchor for the WLAN since it will be the termination point for the client traffic.




It is also important to mention that the WLAN configuration on the production internal and DMZ anchor controllers all be identical with only one exception:

  • Interface - the production internal controllers should have the "management" interface assigned to the WLAN to allow the client traffic to be tunneled to the DMZ anchor controllers. The DMZ anchor controllers should have a dynamic interface assigned to the WLAN to forward client traffic out to the network (this is where clients will obtain IP addresses).

In a failover scenario, once the production internal controller recognizes that the anchor controller is no longer reachable (during the next keep-alive interval), it marks the anchor as Down, de-authenticates clients, forces client re-authentication, and anchors them to one of the remaining Up anchor controllers. Failover could occur because of a controller failure, or even failure of a single port link if not using link aggregation (LAG). In the event of a single port failure, the anchor controller migrates the affected logical interface to the backup port assigned to the interface. Production controller failover to other active DMZ anchor controllers does occur, but re-establishment of the mobility relationship occurs within 10 seconds once the backup port becomes active and new clients are allowed to terminate on the anchor again.

Note - this may result in clients obtaining a new IP address if the anchor controllers are not attached to the same client subnets (perhaps they are in different data centers for instance).

In my testing, failover occurs within 6-10 seconds of taking the anchor controller offline.

There are a ton of related features, requirements, and design considerations for auto-anchor mobility, but this should provide a basic overview.

Cheers,
-Andrew