Forum

Is there any advantage to using a controller based solution when deploying Voice over WiFi?

Controllers provide the following:
1. centralized management and monitoring of AP's
2. aggregation of your data
3. makes L3 roaming possible

Here are some reasons to buy a controller:
1. You can't or don't want to span VLAN's across all your switches.
2. You have enough AP's that changes are very time consuming.

If you decide to stay with autonomous AP's you may want to look at some free tools like Ziptie and OpenNMS. Good luck.

Thanks for the reply. I was wondering more specifically if controller based solutions handled roaming better than individual (not necessarily autonomous) APs.

If WiFi client traffic breaks out locally from an AP and it roams then surely the MAC address table of one or more wired switches has to be updated. This has to be less efficient than all client traffic being tunnelled back to a controller and emerging on to the wired network from there doesn't it?

Is there a flip side to that reasoning?

Does tunnelling client traffic back to a controller present a comparable downside for some reason?

Any views/experiences gratefully received.

I apologize. I didn't really answer your question. So, from an ARP management perspective you are correct that it would be more efficient to have a controller answer for all the devices and only one MAC/ARP table is updated instead of every switch in your network. This is one of the reasons controllers came about. There is one vendor that utilizes the AP's to perform the ARP/MAC forwarding functions. The functionality is very similar except they do this at the edge instead of the core or distribution. There are many advantages and drawbacks to controller based as well as standalone/fat/autonomous AP's. I for one am not a big advocate for voice over WiFi. I think it is possible to successfully implement this but the price you pay for implementing it doesn't seem worth it. In most cases, you will have to disable things like 40MHz wide channels to ensure best practices. If you do not need voice over wifi I would recommend avoiding it. It is possible but there are usually significant trade offs. There are alternatives like IP-DECT, 900MHz, and MDAS. If voice is a "nice to have" then go for it but if it is a "need to have" I would look at a purpose built separate system with dedicated spectrum. That is strictly my personal opinion.

That sounds like good advice. We have offered to quote for an IP-DECT solution but the customer wants to go for VoFi. Luckily they can see the sense in doing this in the 5Ghz band though even though the handsets are more expensive. I just mentioned to them that I thought controller based WiFi was better for Voice deployments in general. They forwarded my comments to their WiFi vendor who can't see why I think that is the case. Not surprising really as their solution isn't controller based!

Thanks for taking the time to reply.

That's unfortunate, I don't think the controller is a deal breaker. 5GHz is better but you will need to stick to UNII-1 and UNII-3 which is channels (36, 40, 44, 48, 149, 153, 157, 161). With 40MHz channels you now have only 4 channels to plan with. You can add UNII-2 and UNII-2 extended but that means it will take 50-100% longer to find an AP to roam to. I know Aerohive doesn't technically have a controller but they still perform the IP roaming function it is just that it happens at the AP. Hey, technically that means they have a tiny wireless controller attached to every AP. So technically, they do sell controllers. Well good luck with that. Just curious are they looking at Polycom/Spectralink, Ascom, or Cisco. I'm noticing that there is a large trend to not talk to people whenever possible and to use iPhones and Blackberries instead of dedicated VoWiFi handsets. Just curious who is possibly getting the business.

We've quoted for Spectralink handsets and their WiFi vendor supports the "SpectraLink Voice Priority" which is a proprietary QoS mechanism from what I can see though I'm not sure the SpectraLink phones do 40MHz channels.

They'll have a Fixed Mobile Convergence client on their iPhones and Blackberries though I see that neither iPhone or Blackberry have 5GHz radios.

The WiFi vendor isn't Aerohive by the way but I'd rather not say who it is.

I guess another factor in roaming without a controller is the quality of the wired infrastructure in terms of performance, load and architecture too.

Thanks again for the advice.

Hi John

Just my two' peneth and I claim not to be a voice specialist, BUT, you are correct with the wired side. It is all too often forgoten about. Primarily the hardware such as switches. Are they capable of supporting the telecoms if its a seperate system at present?

As Jon siad, each manufacturer has its advantage and disadvantages in most sitiuations. My experience with Ruckus for example is they class them selsves as 'management' based as you dont have to puch traffic through the switch as you do with come manufacturers, however for quality of roaming they do recommend routing voice traffic through the switch so it can 'protect' it.
One of the major drawbacks I have seen from controller based is the single point of failure and bottleneck.

I guess a lot will depend on the environment you are using the system in, what interference is already present and the density of users.

I am guessing that the manufacturer was Meraki? Never used them but they are the only ones I can think of outside Aerohive.

Good luck.

CP

Just out of curiosity. Why does it take 50% longer if middle band channels are used?

Hi guys. I thought I would weigh in on this, in order of posting, one-by-one, starting with Wireless Jon's initial post. I hope its helpful.

[b]In response to Wireless Jon[/b]

Aggregation of data is bad. Controllers are notoriously weak management systems, which is why WNMS is usually required. More scalable and resilient L3 roaming is possible without controllers, though not with autonomous APs of course. In order to scale, controller vendors suggest using "distributed forwarding", which requires that VLANs be supported on all of your switches. Centralized data forwarding doesn't scale.

[b]In response to John Eustace[/b]

It depends. If it's a controller-less system, like Aerohive Networks, then roaming is accomplished in the same way as with controllers (by sharing the control plane among APs), only the controller is replaced by a set of free protocols running between APs. Opportunistic Key Caching (OKC) is today's de facto standard, is supported by both controllers and Aerohive's controller-less systems. With distributed forwarding, you're correct that CAM tables have to be updated in upstream switches, and APs do that (Aerohive APs and thin APs from controller vendors who are using distributed forwarding), but this process is extremely fast ( <1ms in most cases) and causes no latency or issue with traffic flows. Distributed forwarding is highly recommended for VoIP because it greatly reduces latency, and tunneling traffic to the network core and back again can introduce a significant amount of latency in some cases.

[b]In Response to Wireless Jon[/b]

It's hard to argue with this response really. I often feel the same way. :) About controllers and controller-less, Jon is right about how things are handled with ARP, though I will add that with controller vendors using distributed forwarding (which is just about everyone these days), APs are doing the work for all vendors now...unlike in the days of centralized forwarding. DECT systems are good, and I see alot of companies using them in Europe, as an alternative to VoIP. There are some VoIP systems out there that work just fine (Vocera for example), but I will say that VoIP systems in general can often be more complex than you might expect.

[b]In response to John Eustace[/b]

In an autonomous AP environment, VoIP will work fine if the security is PSK. In an 802.1X environment, not so much, because you need OKC...and handsets that also support OKC. It's tricky to be sure. With controllers and controller-less (intelligent APs), VoIP will work fine for most vendors. There is no significant advantage between controllers and controller-less for normal VoFi deployments, but there are some weird gotchas here and there that the customer should consider when deploying VoFi. For example, mixing high-density voice with high-throughput data can often be challenging for any vendor.

[b]In response to Wireless Jon[/b]

In adding UNII-2 and UNII-2e, it doesn't really take a client longer to roam between channels, as channel scanning is a background, periodic process that happens all of the time. What you really have to look out for is the client's support of UNII-2/2e. If your infrastructure supports it, and your clients don't, from the clients' perspectives, you have massive coverage gaps. Aerohive supports the same roaming standard as controller vendors - OKC for 802.1X. PSK doesn't need a special fast/secure roaming mechanism. Aerohive's HiveAPs aren't controllers, but they do have the same kind of processing power (CPU/RAM, etc) that smaller controllers have. The control plane doesn't live individually within an AP, but rather between all APs collectively. Think of the Internet as a single system called....well..."The Internet." While it's made up of hundreds of thousands of routers, it's still "The Internet." Same with Aerohive. It's "A Hive", even though it's made up of multiple HiveAPs.

[b]In response to John Eustace[/b]

SVP is going away...and fast. Polycom is now supporting and promoting (as primary) WMM-AC and shortly Voice-Enterprise. This is causing them to rethink their VUE partnership program details.

[b]In response to CraigP[/b]

Craig is correct in that any application that requires fast/secure roaming has to be tunneled through Ruckus's controller. They don't support fast/secure roaming in distributed forwarding mode. They recommend in their design guide that traffic requiring fast/secure roaming be segmented onto a different SSID/profile and tunneled to the controller. I don't personally like to design networks around such limitations. That's just my personal preference, and I'm sure most Ruckus people will claim that all networks should be designed that way...until they can fix that problem at least. ;)

Controllers are no longer needed. They're a bottleneck, single point of failure, additional cost (especially when high availability is needed), and so on. They had their day in the sun, but now they're lingering.

Meraki isn't controller-less at all. They have a cloud controller, and their architecture, per their documentation, extends the control plane into the cloud. That means that if the cloud-controller link is lost, they lose the control plane. The control plane is the functional equivalent of a Wi-Fi system's operating system, controlling functions like fast/secure roaming, WIPS, authentication/reauthentication, and much more.

[b]In response to buckyhead2000[/b]

It doesn't.

Hope this helps,

Devinator