Hotspot 2.0 Can Disrupt the Cellular Marketplace

When it comes to cellular in the U.S. there are two major carriers, AT&T and Verizon, and everybody else. While Sprint and T-Mobile both also compete in the national market, they have far fewer subscribers and a reputation for poor coverage. This has essentially been the state of affairs since Cingular bought AT&T Wireless in 2004 and continued business using the AT&T brand. There are some smaller regional competitors, but their market share is limited, and their customers roam onto one of these national networks when they leave their regional service area.

I think the combination of Hotspot 2.0 and Voice-over-Wi-Fi (VoWiFi), or “Wi-Fi Calling” as it’s known has the potential to disrupt the current cellular marketplace dynamics.

Sprint and T-Mobile have been dropping their prices to try to attract customers away from the Big Two (AT&T and Verizon) for years, even offering to pay early termination fees and give trade-in credit for phones, but it appears that this has largely been unsuccessful. When you can’t make a call from within your own home or office, who cares how cheap the service is?

Part of the problem for T-Mobile is that a lot of the spectrum they own is higher frequency than their competitors, so it doesn’t penetrate buildings as well due to the increase in attenuation that occurs as wavelength decreases. That’s a tough problem to solve.


VoWiFi and Hotspot 2.0 can change all of that.

VoWiFi extends the network’s voice coverage into the subscriber’s home and office, where subscribers can easily connect their phone to the W-Fi network, which takes care of that concern. Sprint and T-Mobile could also partner with SOHO Wi-Fi router manufacturers so that Hotspot 2.0 roaming integration was preconfigured for their networks on these products. Imagine if a subscriber could buy a NETGEAR “T-Mobile Edition” router and have VoWiFi calling work out of the box, without any configuration on their phones.

Imagine if Sprint and T-Mobile aggressively pursued Hotspot 2.0 integrations with major public Wi-Fi providers. Their subscribers would have seamless VoWiFi coverage in the areas where they currently have the biggest problem: indoors. As public Wi-Fi continues to expand, the voice coverage for these carriers could expand right along with it.

In fact, if we assume a properly designed WLAN, in very high density environments the indoor service for these carriers could be superior to the Big Two. Ever go to a ballgame and been unable to make a call or use data in a full stadium? That’s a common experience and Wi-Fi roaming integration solves that. Wi-Fi was designed to meet LAN access needs like this. Why not actually use it that way?

This could make Sprint and T-Mobile attractive again. Although I don’t imagine the costs would be very significant as it doesn’t involve building new towers and deploying more of their own hardware, they would probably need to compensate large public Wi-Fi operators for the use of their networks. That would allow them to keep their service priced below the Big Two.

Cellular data offload is commonly thought of as a driver for the adoption of Hotspot 2.0. Voice coverage expansion for smaller carriers may be more important.

Channel Planning isn’t Easy for Algorithms

If you’ve ever had to create a manual channel plan where spectrum is scarce, you know how hard it is to get it right. You run out of virgin spectrum, then the difficult choice of channel reuse is encountered. Often, what looks acceptable on an architectural plan, doesn’t hold up to post-deployment validation. Two AP’s 6 classrooms away on the same channel can hear each other at a loud and clear -65 dBm RSSI. Reuse the same channel in the classroom directly above, and the signal disappears below the noise floor. An extra inch of concrete make all the difference. To get it right, you have test, change, check, test, change, check, etc.

A 2.4Ghz channel plan

Given the challenge, it’s no surprise that I’ve never encountered an automatic channel selection algorithm that produced better results. At least, not in high density designs where spectrum is scarce, which is more and more just about everything I design. AP’s directly adjacent to one and other end up on the same channel, blasting away at max transmit power.

Speaking of power, I’ve also never encountered an algorithm that satisfactorily handled transmit power control in a high density network. They always turn things up WAY too high. As in, I’m manually taking AP’s that were auto-set from 12-20 dBm down to 4-6 dBm to shrink their cells away from the AP’s that share their channel. That can mean a 10x reduction in power! And even when power levels are auto-set to an acceptable level, I’ve yet to meet an algorithm that proportionally adjusts an AP’s receive sensitivity to accommodate the smaller cell.

Another thing algorithms don’t do well is handle DFS channels. I use DFS channels in many high density designs, but there are always some clients that don’t support them. The best thing to do in that case is to evenly distribute DFS channels throughout the WLAN, and only use them where AP density would otherwise cause non-DFS channel overlap. In those environments I like to alternate non-DFS channels with DFS channels so that clients without DFS support are still within range of a 5 GHz radio they can use. My experience with channel selection algorithms has been that a group of adjacent of AP’s may all be set to a DFS channel, creating a 5 Ghz dead-zone for clients that don’t support DFS channels.

What gives?

This is all too bad because auto channel/power features would be ideal as it dynamically adjusts to changes in the RF environment. A neighbor puts up a new AP on one of your channels and, without intervention, the algorithm moves your AP to clean spectrum elsewhere. In urban environments, this is a highly desirable feature because there is so much RF in your environment that is out of your control.

Every WLAN vendor offers automatic channel/power selection. They all ticked that box a long time ago. But who’s got an algorithm that actually works?

eduroam – Secure, Automatic Roaming Between WLAN’s

eduroam (education roaming) is the secure worldwide federated network access service developed for the international research and education community.

I’ve been really intrigued by the WLAN phenomenon eduroam which has swept across much of Europe and is being deployed in many US universities this academic year. This is a secure WLAN roaming technology, but it doesn’t require Hotspot 2.0/Passpoint/802.11u/Rev 1/Rev 2 (whatever you want to call that).

Participating institutions put up an ‘eduroam’ SSID with 802.1X authentication, and on the back-end authentication is handled by the authenticating user’s home institution’s RADIUS server, rather than the local server of the WLAN. That allows users to establish secure connections to any participating institution’s WLAN.

To get a user on the WLAN, RADIUS requests are proxied by the local RADIUS server to the eduroam regional or top-level RADIUS routing servers. The eduroam server inspects the username in the request for the domain, e.g., matches the realm ‘,’ and then proxies the request to the users home institution’s RADIUS for authentication. The home institution’s server then responds through the same proxying scheme.

eduroam RADIUS routing example
eduroam RADIUS routing example

For users, it ‘just works.’ They connect to the SSID once and add it to their preferred SSID list just like any other network, then their device automatically connects securely wherever they see the eduroam SSID. Could be another university, could be a coffee shop, or even an airport.

For participating institutions, they just need to configure a few RADIUS proxying rules for users outside of their institution, and then users from hundreds of institutions around the world can securely connect to the WLAN.

If my understanding of Hotspot 2.0 is correct, the future for eduroam may be very bright. In a HS2 WLAN, a separate eduroam SSID isn’t needed. eduroam could register to become a HS2 roaming hub, then WLAN operators advertise eduroam through ANQP as a supported roaming hub on their existing 802.1X SSID, and then eduroam users will automatically connect to it. Fewer SSID’s is always better.

While all the talk about HS2 is about offloading cellular data onto Wi-Fi networks, there is real potential here for more useful federated authentication for everyone-not just cellular subscribers. eduroam is the model for that.

Hotspot 2.0: The Future of Guest Wi-Fi?

Hotspot 2.0 is a technology that leverages 802.11u and service provider authentication systems to connect clients to WLAN’s securely and automatically. For example, an owner of a Verizon Samsung Galaxy S5 with Passpoint enabled who comes within range of a Hotspot 2.0-enabled SSID which can serve Verizon customers will automatically connect to the WLAN, secured by WPA2, with no user interaction.

At least, that’s how I understand the most common use case for Hotspot 2.0 and 802.11u. Personally, I have other ambitions for the program and currently it isn’t at all clear what else Hotspot 2.0 is capable of.

I’m encouraged to see that Hotspot 2.0 Release 2 provides a public key infrastructure and pre-installed trusted root certificates on clients for use when forming secure connections to WLAN infrastructure components.

What I’d really like to see if that PKI infrastructure used in a manner similar to HTTPS, so that clients securely connect to an “open” SSID, use EAP-TLS to evaluate the server certificate against its trusted roots, and establish a WPA2 protected connection without any client-side credentials or cumbersome captive portal registration process. 802.11u data can be presented to the client for use in evaluating the certificate. To me, that is the holy grail for WLAN guest networks.

Authenticating users through carrier AAA isn’t important because very few WLAN operators want/need to know the identity of users on their guest networks (with the exception of retail, I suppose).

I must say that I cringed when I read that Release 2 includes “portal based signup.” Hopefully this is substantially different from the extremely mobile-unfriendly process of current captive portal technology. Either way it will be an obstacle to onboarding users. Guest Wi-Fi should be frictionless.

I’m not interested in authenticating guest users on the WLAN, but I do want them to have a secure connection. It would be awesome if WLAN operators could opt-out of all that AAA integration complexity required by Hotspot 2.0 and just use the PKI infrastructure to run an open, encrypted WLAN for guests. This would allow more clients to connect securely as well, rather than only smartphones with with carrier agreements and users that suffer through a portal-based signup process. Will this be possible? I certainly hope so.

School 1:1 Program WLAN Design Considerations

The design of a WLAN to accommodate a school’s 1:1 program can make or break the entire enterprise. A poorly designed WLAN presents connectivity issues, bandwidth issues, co-channel contention, and RF utilization problems that distract end-users from classroom activities and results in a loss of trust in the technology. Similarly, clients with substandard Wi-Fi chipsets will also compromise WLAN performance.

These are some of the important considerations I’ve learned when designing and operating a WLAN to support a school’s 1:1 program.

Wireless LAN

Key points to consider when designing a high-density WLAN to support a 1:1 program:

  • 802.11ac is highly desirable, 802.11n is workable and a minimum requirement
  • Do a site survey to determine optimal AP placements, but design for capacity, not solely coverage
  • Evaluate your switching capacity, including PoE budgets, for AP backhaul
  • Establish client SLA’s before designing the WLAN
  • 5 GHz radios are required
  • DFS channels are required for wide channels or very-high density
  • 2.4 GHz becomes a junk band in high density. Use it only for guest/BYOD clients.
  • Use band-steering to move clients to the 5 GHz spectrum
  • Use the entire 5 GHz spectrum everywhere, and choose channel bandwidths to prevent cell overlap.
    • 80 MHz channels in coverage-areas
    • 40 MHz channels in high-density areas like classrooms
    • 20 MHz channels in really high-density areas such as multi-story classroom layouts
  • Disable low data-rates, all the way up to 24 Mbps. Experiment with going higher.
  • Reduce maximum AP radio power to limit cell sizes
  • Reduce AP radio receive sensitivity to prevent clients at the edge of the cell from associating
  • Use load balancing techniques to spread clients evenly among AP’s
  • Limit SSID’s to as few as possible, generally no more than three. Try this:
    • 1 SSID with WPA2-Enterprise security for school and BYOD devices
      • Use AAA override/dynamic profile assignment (whatever your vendor calls it) to assign security policies, access control, VLAN’s, and QoS policies via RADIUS attributes
    • 1 SSID with no security for guest access
  • Only use WPA2-Enterprise 802.1X authentication. WPA-PSK is a nightmare if you ever need to change the password.
  • Use an MDM solution to distribute Wi-Fi credentials
  • Rate-limit guest and BYOD clients
  • Use QoS to deprioritize traffic from guest and BYOD clients
  • Use layer 7 QoS to deprioritize/rate-limit bandwidth hogs that are not time sensitive including
    • Mac OS, iOS, Chrome OS, and Windows software updates
    • Dropbox, iCloud, and Skydrive syncing
    • Site-specific background data hogs such as an enterprise AV deployment, WSUS server, etc.
  • Track the applications used on the WLAN and use layer 7 QoS to deprioritize/rate-limit bandwidth hogs that are time sensitive, but are only used for recreational purposes on the WLAN.
    • Netflix, Pandora, Grooveshark, etc.

Should time allow, many of these points will become blog posts of their own.

Client Devices

For all of this to work, client devices must meet these requirements. Cheap and used devices rarely meet these specifications. Choose carefully. Don’t compromise.
  • 802.11n minimum, 802.11ac desired
  • The more spatial-streams, the better
  • 802.1X support
  • MDM support
  • 5 GHz band support
  • DFS channel support
Unfortunately many device manufacturers limit the Wi-Fi specs they publish to simply “802.11n” or “802.11ac.” Tracking all of this down is often only possible through testing a device in-person, especially DFS support.

Hello World

I’m the IT Coordinator for a medium size public school district in southwest Ohio. As such I’m responsible for just about anything with a power button, but I have a particular interest in WLAN technology. I operate a high density WLAN to support a K-12 1:1 initiative, which includes Cisco and Aerohive hardware. I have a ACWP certification and am currently pursuing a CWNA certification.

The purpose of this blog is to share my learning experience, thoughts, and questions as my WLAN knowledge and experience grows.

Hopefully there will be information presented here that others will find useful. I encourage readers to comment and create a dialog with me and others in the field.