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