Meru 1020AP Density

[AndyMR2]

Hi Guys,

 

Bit of a broad question I know but is there a recommended AP density with the Meru AP's?

 

We have some that can see 12-15 neighbors and I'm concerned that this may be what's effecting some Voice issues we're having on the wifi.

 

Thanks

[mhowell]

Andy, I work for Meru UK. What exact voice issues are you having, neighbours shouldn't really affect you, however your density of Aps needs to be greater to run effective voice. What voice apps are you running?

How many Meru Aps in total?

thx

[AndyMR2]

Hey, thanks for the reply.

 

At this particular site we have 53 APs each roughly 10 m apart.

 

We've been getting dropped calls & one way voice. The strange thing in the Meru controller is that it's showing a really high number of active calls (around 40) when I know we'd never have more than 3-4 max going at once.

 

I'm not convinced it's a Meru issue and am looking at the PBX and networking as well but just wanted to explore every avenue.

[White_Fi]

Your neighbours may well be affecting you.

 

WiFi is a shared medium.. If your neighbouring APs are causing co-channel interference you are likely to have a higher re-transmission rate which sucks for Voice over WiFi.

Check the air for the best channel to use (cleanest channel with fewest APs and minimum Air utilization), is this 2.4 or 5GHz that your APs are on and is the meru configured for SCA (i guess it is since you are using voice)?

 

thanks

sw

[CyberNerd]

Your neighbours may well be affecting you.

WiFi is a shared medium.. If your neighbouring APs are causing co-channel interference you are likely to have a higher re-transmission rate which sucks for Voice over WiFi.

Check the air for the best channel to use (cleanest channel with fewest APs and minimum Air utilization), is this 2.4 or 5GHz that your APs are on and is the meru configured for SCA (i guess it is since you are using voice)?

 

^ you might be missing the point about how Meru is designed specifically with channel interference and a high density of AP's in mind. Everything runs on the same channel.

[White_Fi]

Yes that is what concerns me. Great if there is no other sources of interference but in a noisy RF environment and other APs that are not playing by the MERU rules are surely going to cause co-channel interference. CDMA/CA - only one STA or AP can talk at once.

 

STA1 is talking to MERU AP1 on channel 11... but a BSS (not MERU) near by is also talking on that channel. The contention increases and clients need to wait longer to speak.

Or lets say that the non MERU BSS is a hidden node and STA1 cant hear it but MERU AP1 can... then you have collisions and re-transmissions.

Edited October 24, 2013 by White_Fi

[mhowell]

AndyMR2. Please PM me or send me your full contact details on email [email protected] and we will get you the CORRECT advice via the correct channels

The information supplied to you is incorrect on this thread by a non Meru party.

Feel free to use my details in future, or I can put you in touch with the right individuals locally

thx

[JettBlax]

^ you might be missing the point about how Meru is designed specifically with channel interference and a high density of AP's in mind. Everything runs on the same channel.

 

Eventually it all comes down to physics. We can manipulate it as much as technology allows, but in the end... physics. The problem with running a single channel is interference. You introduce interference when all APs and clients attempt to communicate on the same channel. Meru's major asset is modifying certain values in duration fields. Think of wireless as a hub. Everyone tries to communicate at the same time. When there is a collision it stops and retries at a random interval. In wireless there is a value inside the packet (NAV value) that tells all the other devices how large it is in essence to attempt to prevent someone else from thinking the channel is clear and sending data. Meru artificially inflates this number for its clients and thus can act as the conductor of your wireless orchestra. In theory, this will allow the system to tell which client when it wants to communicate with it and keep the channel clear from crosstalk. In practice, you have some serious limitations that Meru doesn't tell you about.

 

First, you are only using one channel for your network so no matter what you are limited to the maximum transfer rate of a single channel (or two if using dual band) as if you were the only client. This limits the maximum device density on your network. Secondly power of transmissions become very important. Third, you are putting even more network performance into the hands of wireless nic developers who may not properly test in the proprietary method that Meru uses the 802.11 protocols. Remember Meru only makes up 3-4% of the wireless market share, their proprietary tricks may not be fully supported, especially on legacy devices or BYOD products. If you search the internet you'll find many problems people have with new firmware releases, new nics, dated nics, of all manufacturers including big names like Intel which work by default on other wireless networks. It also creates problems for adjacent wireless networks attempting to use the same channel as the Meru network because they are seeing the traffic and the modified NAV values and thus the Meru system can bring their channel down or prevent proper traffic flow. Definitely not a good neighbor as well should all be using the unlicensed wireless spectrum that must be shared with others. Also, Meru used to broadcast the same SSID and wireless MAC address to the entire network which ended up causing some serious problems with wireless NICs that didn't know how to use the network. So they now have a function where they broadcast a response SSID and MAC to individual clients giving each its own unique wireless network. This adds overhead in additional beacons and extra processing on the AP CPU and WLAN controller, thus reducing overall performance.

 

In terms of density, Meru released a video a couple years back showing they can put 500 devices in a single room and connect them wirelessly. What they didn't initially tell you was that they used many access points and a multi-cell approach using EIGHT 2.4 and 5.0 Ghz channels to do it.

What we do in high-density environments is essentially leverage the single-channel concept so if you can paint the floor with one channel, you can increase capacity by essentially layering more and more channels. So what we did in this particular environment, to support this high-density, was create four channels in the 5GHz range, and these were 40MHz wide, and three channels in the 2.4GHz range and these were 20MHz wide. So we had a total of seven channels.

Interestingly, this document says they used 8 channels: http://www.merunetworks.com/collateral/white-papers/2010-wp-wireless-lan-high-density-demonstration-500-clients-farpointgroup.pdf

Essentially they took a lot of time and money to produce a marketing piece that put 60-65 devices on a wireless channel. In the end, not very impressive.

 

So when you say "Meru is designed specifically with channel interference and high density of AP's in mind" you have to realize the reason they do this is because the system won't work on a single channel without attempting to mitigate normal traffic patterns. But there are tradeoffs. And when Meru wants to demonstrate high density deployments they abandon the single channel approach. The multi-channel blanket architecture becomes cost prohibitive because you would need additional access points to run on separate channels. Also, something to think about.. what happens when someone plugs in an interference device like a microwave or bluetooth? The network can't adapt unless you want to hop everything and all clients to a new channel.

 

This is not to say Meru isn't a good product (as long as you don't like your neighbors), it can do some interesting things with 802.11ac if a customer wants to use a single 160 MHz channel. I imagine most customers would prefer 40Mhz channels to expand their BYOD and wireless density though... as Meru used in their multi-cell high density demonstration. Interestingly their marketing documents say you should use a 160Mhz and it will support large client densities. Take their marketing as you will.

Edited October 29, 2013 by JettBlax

[wotnowires]

The earth is flat, the bumble bee cannot fly, and with algebra you can prove 1 equals 2.

 

This is the same argument that has been made for years 'Oh Meru Doesn't work, laws of physics, NAV, blah, blah'. Unfortunately not all of your 'facts' are correct, combined with the fact that it does work and Meru has thousands of schools in the UK & Ireland alone that will testify to it working. It's not laws of physics that are important here, but the application of the laws of physics. It's not just about SCA, but also the implementation of Meru's Virtualisation which allows for greater scalability and flexibility of your wireless network.

 

AndyMR2, can you tell me which version of firmware you are running in your Meru system? Also which voice handsets you are using? This sounds more like a SIP/Protocol related issue than an RF problem. With some handsets, there are requirements to alter the default QoS settings - as some handsets don't comply with default codec rules. There have also been some issues with the SIP flow detector in older firmware releases which can lead to similar issues to those that you are describing.

 

wotnowires

[JettBlax]

The earth is flat, the bumble bee cannot fly, and with algebra you can prove 1 equals 2.

 

This is the same argument that has been made for years 'Oh Meru Doesn't work, laws of physics, NAV, blah, blah'. Unfortunately not all of your 'facts' are correct, combined with the fact that it does work and Meru has thousands of schools in the UK & Ireland alone that will testify to it working. It's not laws of physics that are important here, but the application of the laws of physics. It's not just about SCA, but also the implementation of Meru's Virtualisation which allows for greater scalability and flexibility of your wireless network.

 

AndyMR2, can you tell me which version of firmware you are running in your Meru system? Also which voice handsets you are using? This sounds more like a SIP/Protocol related issue than an RF problem. With some handsets, there are requirements to alter the default QoS settings - as some handsets don't comply with default codec rules. There have also been some issues with the SIP flow detector in older firmware releases which can lead to similar issues to those that you are describing.

 

wotnowires

I never said it doesn't work. Just that the marketing is misguided. Interestingly I have seen on this forum many Meru employees say "facts" are incorrect, but never care to address their product or do a deep dive. I've even seen threads/posts deleted from this forum for not being favorable towards Meru. If you want to have a conversation about your product and control the messaging on public forums (which you may contribute financially to) you should at least have the respect in your product to explain it to people willing to challenge you on it.

[mhowell]

Whoever you are you show a distinct lack of understanding of Meru's technology.

Meru did not mislead anyone.

It seems very odd that you sign up today simply to post this reply.

There's a customer in Sydney, needing some help, for whom we are more than happy to help, and put in touch with the right support networks locally or direct from Meru, only to see a long post like this

Looks strange to me

Feel free to call me anytime, UK time, and we can talk you through channel layering in more details Here's my details. UK 07919057244 [email protected]

[wotnowires]

JettBlax,

 

I am more than happy to have these discussions, I am however far more interested in ensuring that this customer's issue is dealt with appropriately without being hijacked by others whose singular aim appears to be to attack Meru, not to help.

 

wotnowires

Edited October 29, 2013 by wotnowires

[JettBlax]

JettBlax,

 

I am more than happy to have these discussions, I am however far more interested in ensuring that this customer's issue is dealt with appropriately without being hijacked by others whose singular aim appears to be to attack Meru, not to help.

 

wotnowires

That's a bit disingenuous and I think you know it. He reached out on a public forum and your company has already directed him to contact technical support for advanced troubleshooting off the forum.

Edited October 29, 2013 by JettBlax

[wotnowires]

So as not to be lost in the raised noise floor:

 

 

AndyMR2, can you tell me which version of firmware you are running in your Meru system? Also which voice handsets you are using? This sounds more like a SIP/Protocol related issue than an RF problem. With some handsets, there are requirements to alter the default QoS settings - as some handsets don't comply with default codec rules. There have also been some issues with the SIP flow detector in older firmware releases which can lead to similar issues to those that you are describing.

 

wotnowires

[AndyMR2]

Hi Guys,

Apologies for the extremely late reply.

 

We are using an MC 3200 5.3-132 fw with 1020 AP's. We're using Spectralink 8440 handsets with fw 4.2.1.0003 through a Mitel 3300 PBX. We get exactly the same problem on the MC1500 controllers as well and I am struggling with the support here.

 

The controller shows lots of calls and the IP addresses are often back to front in the to from fields on the controller. We also get the one way voice or dropped calls. We did some Wireshark tests to try to capture it and I've put a diagram together here Gliffy Public Diagram - RFBI Analysis .

 

Appreciate any help people may have.

Edited January 29, 2014 by AndyMR2

[wotnowires]

Andy,

 

Any chance you could send me an email with your contact information and the Meru ticket reference so I can pick this up for you?

 

My email is plambert at merunetworks dot com.

 

Kindest regards,

Paul.

 

Hi Guys,

Apologies for the extremely late reply.

 

We are using an MC 3200 5.3-132 fw with 1020 AP's. We're using Spectralink 8440 handsets with fw 4.2.1.0003 through a Mitel 3300 PBX. We get exactly the same problem on the MC1500 controllers as well and I am struggling with the support here.

 

The controller shows lots of calls and the IP addresses are often back to front in the to from fields on the controller. We also get the one way voice or dropped calls. We did some Wireshark tests to try to capture it and I've put a diagram together here Gliffy Public Diagram - RFBI Analysis .

 

Appreciate any help people may have.

[AndyMR2]

Thanks, have pm'd you and replied to an email from mhowell.

[psydii]

At that density, assuming your walls/floors aren't unusually opaque I would expect to see Channel Layering configured.

 

If Paul wasn't looking into this and you don't have channel layers (i.e. pair up each AP with each member of the pair on a different frequency say AP1 on CH1 and AP2 on CH11, AP3-CH2 AP4-CH11, replicated across the site with a couple of options ticked on the controller to enhance channel selection by the clients) My next troubleshooting step would be see how loud each AP was to its neighbour. If its louder than -65db(*) I'd consider picking an area within the site and disable alternate APs (ie. AP 2, 4 , 6 based on their physical location not their actual AP number) within that area (don't forget space is 3 dimensional so above and below need to be taken into account) and see if you got improvements in client connection stability.

 

 

(*)the idea being that -65db is required between the device and AP for Voice. If you have got that between APs then every time there is a simultaneous broadcast by clients or APs in that area the radios will not be able to differentiate and the signal will be lost, so a reduction in density actually improves things. Meru has mechanisms to minimize these collisions at its very core so it is much better at highish denisty ap deployments than the general competition, but there are limits... That said for channel layers your require pairs (or triads) or APs/Radios to be very close...

 

I wonder whether the people whole installed the wireless understood your intended use case?

[AndyMR2]

Hi Guys,

 

Thought I would update the thread with the resolution.

 

Updated to the latest firmware 5.3.153 and our Spectralink phones aren't dropping calls anymore!

 

One of the bug fixes included in the release:

 

38428 - Issues that caused Polycom phones to abruptly terminate SIP calls and poor voice quality has been fixed

 

While I'm happy with the result it would have been nice to know that this was already a reported issue being worked on. After tearing my hair out for months I can finally sleep a little easier.

[Destinova]

Ultimately this is the kind of slant you are going to get from a sponsored forum...

[psydii]

Ultimately this is the kind of slant you are going to get from a sponsored forum...

 

Hmm. While a solution was provided, getting there was not the best experience for the end user.. And played out in public.

 

If you complain about something in public, you should also follow up to let potential future readers how things turned out.

[featured_spectre]

@Destinova are you a disgruntled former employee or something as you seem bent on railing meru as absolute carp. This is the 2nd thread you've done it on.