4

Here are some real-world issues:

  • Certain client devices struggle to hop across APs in <2.5 seconds, even while awake and in an unsecured network.
  • Many applications don't function with hiccups due to roaming (e.g. VoIP).

Here's my ideal solution:

  • As you connect to an AP, other APs nearby will also transmit/receive the same mirrored packets using the same MAC address.
  • Client operating systems will have no technical capacity to discern when a hop occurs.

Thoughts? What is the closest we can get to that?

EDIT: Perhaps I wasn't explicit enough.

Think of a cell phone. The phone will have a shortlist of multiple connected towers.

When you make a phone call, it uses the strongest connection. When connection to said tower degrades, the call is transferred over to the next available tower with <1ms of Layer 7 hiccup. I want that end result over Wi-Fi.

4
  • 1
    Please explain what kind of authentication the clients are using. Also see this Cisco paper
    – This
    Jun 27 '14 at 10:07
  • This is more of a hypothetical question, so "either none or WPA2-Enterprise," depending on whatever works with the proposed concept Jun 27 '14 at 19:57
  • I'm not sure how the wireless works on telecom side. I believe it works on various frequency bands and could be full duplex. But WLAN is half duplex. Clients contend to gain access to the medium using CSMA/CA. The WLAN APs need to be placed in the right places and make sure there is very less interference and APs are not overloaded with too many clients. If all this is considered and correctly implemented with QOS, then yes there will be minimal loss/delay, otherwise you'll have drops/delay.
    – BHV
    Jun 27 '14 at 20:31
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer.
    – Ron Maupin
    Jan 5 at 22:49
3

It is mostly possible, by using solutions which speed-up association/authentication.

Those are often controller-based, where the central controller is what you're authenticated against, not the individual APs. It manages the APs and global authentication, so it knows you're already authenticated and that you're roaming, letting you associate with its APs much more quickly than if you were using stand-alone APs

Many vendors have such setup, but I'm only familiar with Cisco's and Aruba's

Aruba has a nice solution for small offices/networks, with their Instant AP, where a Stand-Alone AP can be used as a (limited) Controller for 15 other APs

2

Roaming is mostly a client side behaviour. The clients make the decision to roam to a new AP considering various parameters. You can change a few settings on the WLAN card. OS/ NIC knows when to roam to the next AP. For example, If the power from the new AP is better than the older one the NIC/OS will roam to the new AP.

The APs should also have a good percentage of overlap as suggested by the vendor. Any coverage hole will cause the client to drop off.

Also more the number of clients the APs serve, the more is the contention for the medium. This could also cause such problems.

It takes a bit of playing around with the configuration to have the optimal setting and with which VoIP could work well with roaming.

I'm not sure how the wireless works on telecom side. I believe it works on various frequency bands and could be full duplex.

But WLAN is half duplex. Clients contend to gain access to the medium using CSMA/CA. The WLAN APs need to be placed in the right places and make sure there is very less interference and APs are not overloaded with too many clients. If all this is considered and correctly implemented with QOS, then yes there will be minimal loss/delay, otherwise you'll have drops/delay.

1
  • Actually your aggregation network, certainly for large networks, also plays an important role. At some point the upstream aggregator (router/switch) needs to learn the new next-hop (AP). In 3G/4G this whole process of re-learning routes is also part of the handoff and the client knows this is finished as soon as handoff completes. In WiFi that's not as much the case as there is (not yet) any end-to-end standard specifying this process, worst case you lose all downstream until you send at least one upstream to trigger relearning.
    – KillianDS
    Sep 3 '14 at 10:41
2

What you describe is actually similar to the way that Meru Networks enterprise wireless works. The controllers actually attempt to determine the best AP and move the station assignment between APs.

The detractors of this approach will point out that 802.11 doesn't always lend itself to this design. While the system may determine that a certain AP is "best," there is no way it can actually determine the conditions where the client is actually located. This is born out by many wireless troubleshooting tools where most professionals will tell you you need to run them as close to where the clients are to gather the correct information.

Personally, I see flaws on both sides, as the client also can't determine conditions at the AP location so is just as likely to select the wrong AP itself.

However, 802.11 is always advancing and improving, especially when it comes to sharing information between station/network and faster roaming. Several amendments of note in this aspect are 802.11k, 802.11r, and 802.11v which have all been approved and rolled up in the 802.11-2012 maintenance release. Two additional amendments going through the approval process are 802.11ai and 802.11aq.

1

No matter how the APs are configured, there will still be a delay, or hickup, present. You can experience the same thing with the cell phone carriers - especially - I don't know why - if you are moving fast enough, like in a bullet train, when the switch happens, there will be a momentary loss.

When a device is roaming, it goes through three phases:

  1. Scanning: As the device roams and starts to get away from the AP, the Received Signal Strenth Indicator(RSSI) starts to flactuate and go under predefined levels. When this starts to happen the device seeks for alternate APs. After discovering the APs, the device selects the appropriate AP based on the criteria defined on the device itself.

  2. Authentintication: At this stage, your device sends authentication request to it selected in the scanning stage, and waits for either an approval or rejection.

  3. Reassociation: When the new AP authenticates the device, the device sends an reassociation request to newly selected AP. After (if) the new AP approves the request, your device sends a disassociation request to the old AP, so that it is removed from the old AP's tables.

The whole process is known as handoff. Typically, it takes less than half a second. The reason behind the losses longer than half a second is due to the client device's decision mechanic to decide when to drop one AP and switch to another. Some devices have more comprehensive methods to decide when to "roam", others may just stick to RSSI levels dropping below some predefined value.

Therefore, if you are having hickups longer than half a second, I would advise referring to your device's manual or consulting with the manifacturer to see whether the culprid is actually your device. In that case, I would suggest exploring different vendors.

1
  • Does it appear that way? I did not mean to sound like that. I wanted to point out that roaming is client-side dependent and therefore the client should be investigated first. How should I word it? Jun 27 '14 at 12:46
0

We've dealt with these scenarios before as an MSP. One place was solid concrete construction, so the areas had to have their own AP's. We also have a client that we manage that takes up a large scale shopping center for their operations. We've done surveys to determine best placement of devices for handoff. The best solutions we've found is carrier-class equipment (wisp). Ubiquiti has a great controller based system called UniFi, with some great paired AP's. Another one being Meraki.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.