4

I have multiple Wi-Fi access points in my house. What's the best practice, should I use the same or different SSIDs?

I currently have different SSIDs because I like to know which AP I'm logged in to. But handover takes ages. Would that work better/faster when using just a single SSID?

My clients are mostly iPhones and iPads and the APs are non-Apple (AVM Fritz!Box and Digitus).

4
  • 1
    I use different SSIDs - because they really don't like to switch over if they can still get a sniff of the current connection. Sometimes it's easier to just force them over to the nearest.
    – Tetsujin
    Commented Mar 23, 2015 at 19:34
  • 2
    I use same SSID over 3 APs and it works just fine.
    – Ruskes
    Commented Mar 23, 2015 at 19:45
  • 1
    About the handover time, which channel scheme are you using? Is it the old one1..14 coming from the 802.11b 15 years old, or the 36..64, 100..140 802.11ac scheme? Depending on this scheme choice, your wireless architecture choice will be different. Anyway, the network name must be the same for any form of handover. There is no such thing as an handover from network A to network B.
    – athena
    Commented Mar 27, 2015 at 13:16
  • Daniel, I'm using both 2.4 and 5 GHz channels. In the 2.4 GHz band I've used only 1, 7 and 11 to prevent crosstalk. What you're saying makes sense. See my answer, by using the same SSID the handover actually works. Commented Mar 27, 2015 at 17:25

4 Answers 4

8

You can have the same SSID for multiple APs, this is how our campus network is set up, but there is a caveat that's worth knowing. When moving between APs we've noticed OS X has a tendency to "stick" to the first AP it has joined even if it's in the presence of another AP offering a stronger signal. Cycling the wi-fi can help with re-association to an AP with a stronger signal, but the fact is it doesn't always switchover automatically. Unlike Windows which allows you to tune the aggressiveness with which it searches for better APs, OS X offers no easy control over its wireless behaviour.

This may seem like a non-answer but you may find you have as many issues (albeit slightly different) with a single SSID when compared to a network with multiple SSIDs.

My advice would be to try it for yourself and see how it works for you. Be prepared for some experimentation with setting wireless power levels on your APs so you can have some overlap between APs, but not so much that OS X will doggedly stick to the first one it finds.

2
  • 1
    Good idea to experiment with power levels. I usually set it to 100% (and choose non overlapping channels such as 1, 7 and 11) but I'll try if lower levels help force the switchover. Commented Mar 23, 2015 at 19:55
  • You might replace your " can " in your first santence by a " should ". How would any handover behave when connected to a network named Boeing internal WLAN in presence of 2 neighbour wireless networks named McDonalds and Starbucks Coffee?
    – athena
    Commented Mar 27, 2015 at 13:22
2

I've changed the setup to use the same SSID for all APs and I observe much faster handover times, at least on my iOS devices. Haven't done yet any tests with Macs though.

So far I haven't reduced power levels as @ScunnerDarkly suggested because I'm satisfied with the results right now.

1

It seems like you are pretty up on WiFi, so I won't go into all the inner workings. However, you did mention that the "handover takes ages."

The handover is handled by both the device AND a controller. There is a setting (and generally not accessible by users) at what threshold the adapter begins looking for another good network. It is taking ages because it takes that long for the signal to drop off. Once it does, your device connects to next available, strongest network.

Simply speaking, the controller helps with this process by monitoring signal strength of the connected device and then kicking off the low ones to force a rejoin.

Since those controllers cost mega $$$, it is much easier to just toggle Wi-Fi on/off. Setting your AP SSID is now just a matter of preference.

6
  • So you're saying that professional Wi-Fi APs monitor client signal strength and kick off the weak ones? Commented Mar 23, 2015 at 19:58
  • 1
    Not the AP's themselves. In "pro" installs, they are basically dumb AP's with no management whatsoever. They are connected to a controller which does all the management for them including monitoring signal strength. The Ruckus WiFi infrastructure that I recently deployed handled all of the hand offs for me based on a threshold that we could set. It worked beautifully.
    – Allan
    Commented Mar 23, 2015 at 20:03
  • 1
    We have a reasonably large Meraki/Cisco deployment which is definitely "enterprise class". Our Windows clients don't generally have roaming issues, and our iOS devices behave well between APs - it's just OS X that causes occasional issues. Unfortunately, while we have visibility of the Meraki dashboard we don't have full control as our network is managed by a (not particularly proactive or responsive) 3rd-party. This changes in August when we'll start managing in-house so hopefully we'll be able to fine-tune things for our OS X clients. Commented Mar 23, 2015 at 20:08
  • I am familiar with the Meraki/Cisco products (from the sales demos). We went with Ruckus because we thought they had a better product. I don't recall getting any issues with the OS X clients, but those devices were few and far between. We did have a ton of iOS devices and Windows clients and all worked beautifully.
    – Allan
    Commented Mar 23, 2015 at 20:28
  • So in theory, lowering the power level of my AP should reduce the handover time, right? So I have to find a good balance between short handover times and a strong-enough signal? Commented Mar 23, 2015 at 23:30
0

This Apple documentation (linked from this one) suggests, for a roaming network, to "configure the Wireless Network Name, security, and password on each Wi-Fi base station to be exactly the same".

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .