Outdoor Wireless Access Point

Mon Apr 2 00:35:48 UTC 2012

Joel Maslak 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 all clients wait until they lose connectivity
> to start looking for another AP - it depends on how the client
> was built.

The problem of looking for another APs is that, to scan existence
of other APs with reasonable reliability, clients must listen to
other channels for considerable amount of time (three times
maximum beacon interval, maybe), during which the clients can't
receive packets from the current APs.

That's why most, if not all, clients search new APs only after
they loss connection with the current APs.

> However, even without needing to lose connectivity
> to learn what other APs are nearby, there still is a
> substantial associatiation delay with EAP.

That's not a problem, in this case, when all the servers will
be located in a university campus.

> That's why 802.11r + 802.11k exist.

I'm afraid it is a L2 implementation of broken idea of PANA.

>> 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 devices when you add new APs.  It has the
> disadvantage of not being a COTS solution AFAIK.

It is because the currently recognized commercial demand is to
have smooth migration between 2/3G and WLAN, for which two
RFs one for 2/3G and another for WLAN is enough.

> Another way to do it is Meru's "one frequency, one MAC" approach.

"one frequency, one MAC"? I think it does not eliminate overhead
of channel scanning, or, does it?

> As for locating other access points, even without 802.11k, most
> solutions I have seen go into power save mode for long enough
> to do a quick scan every once in a while, taking into account
> the size of the phone's jitter buffer.  That causes the AP
> to hold packets until the scan finishes.  So one channel is
> not required for fast roaming.

Then, very short beacon intervals must be assumed.

> But with smartphones capable of running VoIP clients, I'd be
> less inclined to do it that way even if I thought WEP was
> secure-enough for voice calls.

Smart phones makes the situation worse.

With applications with high speed communication, 50ms loss of
communication can be significant. At 12Mbps, twenty 1500B
packets are lost in 50ms.

> Supporting VoIP handoff is much more complex (and, at least
> from what I've seen, expensive) than supporting web browsing
> handoff.

Both of them are difficult in their own way that the complete
solution (within WLAN SS, between 2/3G and WLAN, between WLAN
of different service providers etc.) can be found only at L3
layer, IMHO.

						Masataka Ohta