[151871] in North American Network Operators' Group
Re: Outdoor Wireless Access Point
daemon@ATHENA.MIT.EDU (Joel Maslak)
Sun Apr 1 19:10:00 2012
In-Reply-To: <4F78CC34.7020603@necom830.hpcl.titech.ac.jp>
From: Joel Maslak <jmaslak@antelope.net>
Date: Sun, 1 Apr 2012 17:09:12 -0600
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Apr 1, 2012, at 3:44 PM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>=
wrote:
> With 802.11, you can connect to an AP and, if the AP
> fails, you may be connected to another AP, but the
> transition takes considerable amount of time not
> tolerable for voice communication, which is why it
> is not called mobility.
True under basic 802.11, at least with WPA2 + EAP, for some clients. Not al=
l clients wait until they lose connectivity to start looking for another AP -=
it depends on how the client was built. However, even without needing to l=
ose connectivity to learn what other APs are nearby, there still is a substa=
ntial associatiation delay with EAP.
That's why 802.11r + 802.11k exist. I'm sure the big name vendors support t=
his and also support their proprietary alternatives that may or may not be b=
etter.
> If you want mobility, have different SSIDs for APs in
> the same frequency band (or, let terminals have multiple
> sets of radio interfaces) and let terminals connect
> to multiple APs simultaneously.
That's one way of doing it, provided you have a way to manage all the end de=
vices when you add new APs. It has the disadvantage of not being a COTS sol=
ution AFAIK.
Another way to do it is Meru's "one frequency, one MAC" approach.
As for locating other access points, even without 802.11k, most solutions I h=
ave seen go into power save mode for long enough to do a quick scan every on=
ce in a while, taking into account the size of the phone's jitter buffer. T=
hat causes the AP to hold packets until the scan finishes. So one channel i=
s not required for fast roaming.
I've seen solutions cope without 802.11r + 802.11k by using a WEP-only SSID o=
n each AP (typically the same SSID for all APs) and throwing that into a VOI=
P-only VLAN. But with smartphones capable of running VoIP clients, I'd be l=
ess inclined to do it that way even if I thought WEP was secure-enough for v=
oice calls.
The other solution that I've seen some things support is to use WDS on the V=
oIP device. I'm also not a fan of that personally, but others may be. WDS w=
ould require one frequency throughout the network however.
> Though you only have to modify software on terminals,
> AFAIK, there is no such commercial products.
There are plenty of commercial products that support VoIP handoff without is=
sues. Some are proprietary, some are open standards. Many support multi-ch=
annel networks. It starts to get expensive to do this though, as most (all?=
) of the cheap vendors don't do what is required on the AP side. That said,=
I'd love to hear I'm wrong on this - I'm looking for new APs for home.
So, if I was buying an enterprise 802.11 solution and needed to support seam=
less VoIP roaming, I'd look at either a one-vendor solution (I'm sure Cisco p=
hones + Cisco APs + Cisco Controller + Cisco PBX would do this just fine, fo=
r instance; you can substitute a few other big vendors for Cisco, no doubt, a=
lthough not likely cheap ones; you'll be spending 10x or more per AP in many=
cases than if you could have used the cheap ones) or someone that complies w=
ith 802.11r + 802.11k (both for handses and APs). Obviously your network be=
tter support DSCP and/or VLAN priority marking and WMM as well.
Supporting VoIP handoff is much more complex (and, at least from what I've s=
een, expensive) than supporting web browsing handoff. It's also what sepera=
tes different pricing tiers of wireless equipment.
