sniffwifi

Just another WordPress.com site

Archive for the ‘802.11v’ Category

802.11v: Keep Dreamin’ (in iPhones running iOS 7, at least)

with 3 comments

I’ve seen a lot of 802.11 amendments in my day.  From speed (ac) to security (i) to voice (e), a lot of those amendments have done great things.  But 802.11v isn’t going to be one of them.  One look at an iPhone’s (iOS 7 iPhone, that is) 802.11v capabilities shows that the dream of Wireless Network Management delivering client control is still just that: a dream.
It has long (well, for a dozen years or so) been a desire of WiFi admins to have more control of client/stations.  Control over which AP the client will connect to.  Control over what signal strength (or signal-to-noise ratio [SNR] or error % or BSS density) will trigger client roaming.  Control over which Final Fantasy character they will assume at that weekend’s LAN party.  (I know virtually nothing about video games, so feel free to make dumb jock jokes at yours truly’s expense.)
For about half as long, WiFi admins have had hope for client control on the horizon: 802.11v.  The wireless network management (WNM) amendment was created to (quoting from the 802.11v Abstract), “provide WNM enhancements [blah, blah, blah] to effect a complete and coherent upper layer interface for MANAGING 802.11 DEVICES in wireless networks.”  “Managing 802.11 devices” is the key part there.  The hope was that with 802.11v, a WiFi admin would be able to pause his (or her) game of WoW, slowly turn 15 degrees to the right (so as to avoid rupturing a clavicle from sudden movement) and use his (or her) wireless network management system (WNMS) to manipulate smartphone/tablet/laptop/etc. associations to the various BSSs in his (or h… oh, you get the point) enterprise.  
***
I’ve often been asked the question, “why weren’t 802.11 WLANs designed to allow centralized client control in the first place?” just before a snack sized bag of Doritos gets emptied ass-over-tea-kettle into a network admin’s mouth.  Well, the answer is, “because the AP doesn’t know sh*t.”  APs are mounted above your ceiling (or below your ceiling or, if you’re really doing it right, on your walls).  There ain’t no clients above your ceiling (or below your ceiling or on your walls).  So having an AP that’s above the ceiling (meaning an AP that only really knows RF information about the area above the ceiling) make decisions for a client that’s on a desk or walking down a hallway is poor form.  You want the right RF information so that you (hopefully) get the right decision.  Only the client knows the RF information about its current location.
***
802.11v was supposed to be special because it (optionally) allows APs (or controllers or WNMS) to make decisions about client associations.  802.11v took RF information that the client sends to the AP as part of 802.11k radio resource measurement (RRM) and WiFi information that the client sends as (another optional) part of 802.11v and gives the WLAN infrastructure (APs, controller and WNMS) the ability to paint a picture of the client’s RF environment.  If the AP thinks that the client would be better off on another BSS (which likely would mean another channel), then the AP could use WNM to force the client/station to make that move.
The problem with all of this is that is was never going to happen.  (I use “was” instead of “is” to convey the notion that, not only is it unlikely that infrastructure-based association management will be adopted any time soon, but that it was never prudent to assume that makers of smartphones/tablets/laptops would ever cede control over associations to WLAN infrastructure vendors.)  The authors of 802.11v even ended up making infrastructure control over associations optional because they knew that device vendors wouldn’t adopt WNM otherwise.
Which brings us back to the iOS 7 iPhone.  iOS 7 iPhones do support 802.11v WNM.  You can see it in the Probe Request frames that iPhones send whenever they are unassociated to WiFi.  If you look in the frame body of a Probe Request and scroll down to the Extended Capabilities, you will see WNM information.  It’s tricky, because the WNM information is mixed in with information from other 802.11 amendments.  But if you look at this frame decode (from Wireshark, because I’m lazy and didn’t feel like booting into Windows), you’ll see it:
You see in octet 3 where it shows “Multiple BSSID”?  That’s WNM.  So is “SSID List” in octet 4 and “Geospatial Location” (should’ve been soldered as “America!” in the standard) in octet 2.  
And you know what you see for every single WNM capability seen in that iOS 7 iPhone decode, save one?  0.  “Not supported”.  Apple is giving WiFi admins The Heisman.  They are not allowing your WLAN infrastructure to have any sort of association control.  And what’s more, Apple is not even allowing its precious iOS 7 iPhone to even give the APs/controllers/WNMS any additional information.  (My guess on the reason is battery life, but with Apple who knows?  They’re the kind of company that will foster a pro-gay rights environment for years, champion the cause of gay marriage publicly, and then seemingly go out of their way to keep the fact that their CEO is gay under wraps.  They’re an odd bunch up there in Cupertino.)  In fact, the only part of 802.11v WNM that an iOS 7 iPhone does support is a part that could potentially harm the WLAN infrastructure: directed multicast service (DMS).  (DMS allows client/stations to request than an AP sends multicast traffic as a directed [unicast] frame.  This is probably supported because captive portals featuring web authentication are especially annoying when using Apple devices.  Apparently some guest WiFi services use multicast frames to check whether authenticated clients are still present.  Since many [most? all?] Apple devices sleep through multicast frames if no multicast-based app is running, the end result can be an iPhone/iPad/MacBook user having to re-authenticate to the stinky captive portal dozens of times per day.)
So, at least for now, the dream of centralized management of WiFi clients is dead.  802.11v WNM is approved.  It’s supported.  And all of the parts that would allow network admins to stay at their desks monitoring the fantasy football waiver wire while controlling client associations have been stripped out.  Client/stations continue to control associations and designing the RF environment for your clients’ behavior continues to be the way to get iPhones associated to the right BSS.
If you like my blog, you can support it by shopping through my Amazon link.  Same Amazon store and prices, but I get a kickback.  Thank you.

Written by sniffwifi

January 2, 2014 at 5:54 pm

Posted in 802.11v, iOS 7, iPhone, Wireshark, WNM

Cutting Though Traffic Like a Flying V

with 4 comments

The 802.11v amendment has been voted, stamped and added.  It is part of the 802.11 standard.  We still are unsure if we’ll ever see it, but if we do it could ease some concerns about high-density WiFi.

Wireless Network Management is its name, and not being adopted is 802.11v’s game.

Wireless network management (WNM) is an addition to the 802.11 standard that puts more control in the hands of admins.  Today, the client/station controls everything: roaming, load balancing and congestion avoidance included.  WNM is designed to put that stuff in the hands of the infrastructure (APs, controllers and management software).

Companies that sell client/stations have (predictably?) declined to adopt WNM thus far.  That means that admins will continue to have to wait for the ultimate careful-what-you-wish for WiFi technology.

There is, however, one part of WNM that is separate from the move to infrastructure control: Multiple BSSID Beacons.  APs have supported multiple BSSIDs for a long time (and Beacons for even longer), but until 802.11v/WNM, the two were never put together.

Multiple BSSID Beacons are important because they could cause a reduction in channel overhead.  Many WiFi networks that support an array of users are hamstrung by the fact that each BSSID takes up about 2.5% of available 2.4 GHz channel time.  (I wish I could take credit for that calculation, but it was an engineer from Ascom who did the math and relayed it to me.)  That means that a hockey arena deployment that supports separate SSIDs for Team, media, concessions, ticket scanning, audio/visual and guests would lose 15% (6 x 2.5%) of available channel time from each AP.  If the big open spaces like the arena bowl have areas where APs on channels 1, 3, 5 and 7 (a bad channel design, but it happens) are covering the same space, then each of those APs would be losing somewhere between 45% and 60% of available channel time before the first data frame is sent.  If all six of those SSIDs could be contained in one Beacon, the Beacon overhead could be reduced to 10% or less on each channel.

Who knows if 802.11v/WNM Multiple BSSID Beacons will ever be adopted.  Hockey fans already saw the Flying V cut through the neutral zone trap to perfection, only to have it go unadopted by those stodgy NHL coaches.  Let’s hope that WiFi vendors treat our V differently.

Written by sniffwifi

August 5, 2013 at 10:34 pm

Posted in 802.11v, WNM