wotnowires

Hi all, On the subject of 11ac, it is interesting that some wireless vendors are playing down 802.11ac and its benefits in 'Wave 1'. Generally, this is because the benefit of 11ac at this point comes from 80MHz wide channels, and multi-channel architectures have issues deploying with the wider channel widths. Consider a vendor recommending 40MHz channel width vs an 802.11n solution: 1x1:1 11n @ 40Mhz = ~ 150Mbps 1x1:1 11ac @ 40Mhz = ~ 200Mbps Multiply this up as the spatial streams increase, but you are only seeing a 30% uplift in moving to 11ac. Not a massive improvement when using 40MHz channels. Now think about an 80MHz 802.11ac solution vs the same 11n solution: 1x1:1 11n @ 40MHz = ~ 150Mbps 1x1:1 11ac @ 80MHz = ~ 433Mbps This is almost 300% of the performance of the 11n solution - a real benefit to 802.11ac today. Again, multiply up as you increase the number of spatial streams. With regards to Meru and needing to pass the traffic through the controller, this isn't the case and hasn't been for many many years. There are many implementations of Meru utilising centralised (datacentre deployed) controllers with AP's in schools, these wouldn't be possible without the ability for the AP to bridge data locally. Each ESS Profile/SSID can be uniquely configured for distributed/bridged or tunnelled dataplane mode depending on requirement. I guess my question is, if you are deploying WiFi today, why would you choose a 7 year old technology/standard? It's your call, but there are a few things I think are important to consider. Firstly, although the standard was only ratified this year, on average I am seeing 7-12% of devices being 802.11ac in public events. Apple and Samsung are committed to 11ac as is evident in their latest hardware. The next generation of iPad and iPhone are expected to be sporting 11ac chipsets, and Samsung is now shipping MIMO 11ac chipsets in it's latest hardware. Dell, HP and Lenovo among others are now shipping 11ac chipsets in their newer laptops. Predictions I've seen from chip vendors such as Broadcom, are that they'll be shipping almost only 11ac chipsets by the end of the year. Secondly, multiple vendors are reporting improved performance for legacy/802.11n client devices - of upto 40 percent depending on the client chipset. This offers a large increase in performance without the use of 802.11ac client chipsets. Thirdly, 802.11ac is coming in with little or no price uplift over 11n (for enterprise vendors as a whole). With this in mind, I again find it hard to understand the choice of an older 11n technology. It is entirely your choice as to which technology you choose, but I hope you take a good look at what is out there and listen to all sides of the story - my advice would be 11ac regardless of which vendor you choose, and don't forget that you are looking to support your clients for the coming 3-5 years (depending on your purchasing cycle) and that you need to consider what your aims are for teaching and learning in that time (including BYOD, which will certainly bring a plethora of 11ac devices to your network).

Mr Noisy, Would you mind sharing your contact information with me via PM? I have dropped you a message, and would be keen to work with you to get to the bottom of your issues.

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.

steves22, can you confirm which version of System Director you are running? Paul.

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

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

Which Android device did you test with? All of the other devices that 'worked' appear to be 5ghz capable. The AR5007 is not. It is a single stream 2.4ghz only device. Have you run any non-wifi interference scanning? I'd suggest forcing one of your AP's to channel 1 and trying again (as channels 6 and 11 are most frequently impacted with non-wifi interference). This aside, as per other posts, I'd take a look at your driver version (make sure it is up to date), and also ensure your wireless power saving is disabled (Windows 7 power profile, set WiFi to Maximum Performance). You'll often see that with Maximum Performance your devices will work better at density, in turn reducing the power consumption! 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

Over many years of working with wireless, one thing I have been overwhelmed with is the time and effort that can go into the selection of a Wireless LAN infrastructure. Research into each and every Wireless LAN vendor, and there are a number of us, is tirelessly (or so it seems) undertaken, trials and proofs of concept are run, references are taken, and then the most suitable technology (hopefully) is chosen. This is as it should be. The thing that surprises me however, is how often little or no time or effort goes into investigation of the other half of the equation - the WiFi chipset within the mobile device. But 802.11n is 802.11n, right? Not quite.... I am sure many of you know this, but I thought it would be good to just give a brief overview of what difference there is in the capabilities of different implementations of the 802.11n standard. Firstly, with 802.11n, we have the ability to run within either the 2.4GHz or 5GHz frequency bands; commonly known as 11bgn and 11an, respectively. Each of these runs separately from the other, and most enterprise class WiFi vendors would specify dual band access points for educational campuses. Secondly, 802.11n added MIMO (Multiple In/Multiple Out) capability. By utilising multiple antenna chains per radio, it is possible to send multiple data streams simultaneously, each carrying additional data. The standard allows for up to 4 spatial streams. Most enterprise WiFi vendors would specify either dual or triple stream access points for educational campuses. Thirdly, 802.11n allows for the use of varied channel widths. Both 20MHz and 40MHz channel widths are configurable. The benefit of a 40MHz channel width being slightly greater than 2x performance over 20MHz. So what does that mean for me??? The easiest way to show the impact of this variance in implementation of 802.11n is by looking at the achievable data-rate for each combination of Spatial Streams and Channel Widths. [table=width: 500] [tr] [td]Datarate based on Channel Width and Number of Spatial Streams[/td] [/tr] [/table] [table=width: 500] [tr] [td][/td] [td]Channel Width[/td] [/tr] [tr] [td]# Spatial Streams[/td] [td]20MHz (With SGI)[/td] [td]40MHz[/td] [/tr] [tr] [td]1[/td] [td]65Mbps (72)[/td] [td]150Mbps[/td] [/tr] [tr] [td]2[/td] [td]130Mbps (144)[/td] [td]300Mbps[/td] [/tr] [tr] [td]3[/td] [td]195Mbps (216)[/td] [td]450Mbps[/td] [/tr] [tr] [td]**4[/td] [td]260Mbps (288)[/td] [td]600Mbps[/td] [/tr] [/table] **As there are no commercial implementations of 4 spatial streams that I am aware of (happy to stand corrected), any comparisons to follow will be based on 1, 2 and 3 spatial stream implementations. So, as you can see, there is huge potential for variance in performance of your wireless network based on the devices you choose. If you were to choose, for example, a Broadcom 4313 WiFi chipset, you would be limited to 20MHz operation and a single spatial stream in just the 2.4GHz band. If, however, you were to choose instead the Intel 6300 chipset, you would have access to 40MHz operation and three spatial streams in both spectra. In a standard classroom deployment with 30 devices running on a single AP, the BCM4313 solution would be limited to 65Mbps (or 72 with SGI) aggregate across all devices, whereas the Intel 6300 based solution would achieve up to 450Mbps aggregate on each of the bands, totalling up to 900Mbps. This equates to an increase to 12.5x (with SGI) performance through the use of a different '11n' device. Finding out which WiFi chipset your device vendor has chosen to implement isn't always that straight forward - but worth it if you can see a 13x performance increase wouldn't you say? In order of preference, I would demand dual band as a minimum. Dual band WiFi chipsets are available in Mobile Phones, Tablets, Netbooks and Laptops. Then I'd look to push for multiple spatial stream capability, but remember, if you have a dual stream AP, then a triple stream client won't help! 40MHz capability is normally a given on 5GHz capable devices, but not all - so worth checking for! Where do you check??? Well, the WiFi alliance is a great place to start. They have a search facility available at Certified Products Advanced Search | Wi-Fi Alliance . If you speak to your device vendor, and find out the 1500 notebooks you are looking to purchase contain the Realtek 8192CE WiFi chipset, then goto this page and search for 8192CE where you can then view the WiFi certificate for the device. Within this certificate, you can see that the device is only certified for 2.4GHz, but that it does support 2 spatial streams, both for transmit and receive. It's not the slowest device on the market, but maybe you should at this point consider checking with the laptop vendor if they have an alternative WiFi chipset available that supports both 2.4GHz and 5GHz - after all, it'll allow you at least twice the performance from your WiFi infrastructure than the 2.4GHz only device, and typically shouldn't be too much more expensive. What about 11ac? Well, 802.11ac both simplifies and complicates things (if that's possible!). The good news, is that 802.11ac mandates 5GHz operation. It is however possible to have a 5GHz only device, although all implementations I have seen to date include 2.4GHz operation for 802.11bgn. On the flip side, there is a greater variance in the numbers of spatial streams (1-8 by the standard) and the channel widths available (20MHz, 40MHz, 80MHz and even 160MHz when 2nd Generation 11ac chipsets hit the market). The key thing here will be to ensure that any 802.11ac access points you are looking at today support the current maximum capability - 3 spatial streams and 80MHz wide channels (this is based on my current understanding of the market; 4 spatial streams and 160MHz channels are expected in late 2014 or even early 2015). The same principles will exist for your client devices as above. I guess the key thing I am getting at here is that It Takes Two to WiFi. You can buy the meanest, fastest, most capable WiFi infrastructure in the world, but if you load it up with single band, single stream WiFi devices, it's just a waste! I am not sure if you will find this post useful, however I am happy to answer any questions you may have on the subject! -------------------------------------------------------------------------------------------------- The comments and opinions here are my own and do not necessarily reflect the views of my employer! --------------------------------------------------------------------------------------------------

Steve, Are they showing as Online/Disabled or Offline/Disabled? If showing as Offline/Disabled, then this suggests that there is no communication between the AP and Controller - can you check the LED status of the AP's? Have any changes been made to your network from a VLAN perspective at all? I would recommend that you create an A record in your DNS server of wlan-controller and point it at the IP address of your Meru controller. This will allow the Meru AP's to locate and communicate with their controller across Layer 3 boundaries - assuming that there are no ACL's in the way. Which AP's are you using?

Hi Rob, Not sure if this is still an issue for you? The ports required depend on the configuration that you are trying to implement. The standard communication ports for the AP are: UDP 9292,9393 and 5000. These three will need to be forwarded to the Meru controller, and will work perfectly well through NAT. If you are looking to use the VPN capability in the newer Meru AP's, then you'll need to forward just UDP port 1194. For future reference, you can connect to the Meru AP using a console cable. If this is an AP320 or AP1020, then you'll need an RJ45 console cable. For the AP332 or AP832, you'll need a specific jack cable (available for little cost from your Meru reseller). The console settings are 115200,8,none,1,none. Once connected to the console, you should see the discovery process take place. The Meru AP can communicate with the Meru Controller either via "Layer 2" or "Layer 3". Layer 2 uses a bespoke ethertype, whereas Layer 3 uses UDP/IP. Out of the box, the AP will default to Layer 2. In this mode, it will attempt to discover the Meru Controller using the Meru ether protocol. If this fails, it will also attempt Layer 3 communication, using either DHCP option 43 or DNS with a hostname of wlan-controller to determine the IP address required to communicate with the controller. When using the VPN capability of the newer AP's, the same UDP/IP ports are in use, but through an OpenVPN tunnel on UDP 1194.

Rob, The Android devices will likely use a different algorithm to determine when to go to sleep. - Maybe less aggressively. I just tested this with my iPhone and saw my ping drop to a steady 2ms as soon as I started to stream from iPlayer. A packet capture shows the device indicating that it will go to sleep regularly. Kind regards, Paul.

Hi there, Just had a good look at this, and I am reasonably confident that the issue you are reporting is to do with WiFi powersaving on the iOS device. Just tested on my own client, and I see high ping times, however if I then start streaming video these pings drop to a more reasonable 5-10ms consistently. With legacy WiFi powersaving, a Station (wireless client), is able to indicate in each packet if it is going to go to sleep. When in a sleep state, an AP is only able to wake that client once per DTIM interval (usually one beacon or 100ms by default). The AP indicates in the TIM portion of the beacon (which the client wakes up to listen to) that it has data waiting for the client. The client then wakes up and sends a PS-POLL frame to the AP to indicate it is ready to receive any buffered data. As there's only the opportunity to wake a client once per 100ms, this will easily show an increased ping of 100-200ms (dependent on how quickly the client can wake, get access to the medium, send a PS-POLL and then have the AP schedule and tx the buffered data). Hope that makes sense? Kind regards, Paul.

Hi Kenny, Could you confirm if YouTube works via the browser on the iPad? If I remember rightly (and I may be wrong), the app uses a different method of accessing content to the web page. It is common for proxies/filters to filter the app but not the web interface... Kind regards, Paul.

Mitch, Do you have multiple ess profiles bound to a single vlan? If so, can i ask which Meru System Director version you are running? You may need to update to version 5.1 as the earlier versions of code only supported multicast in a 1:1 ess:vlan configuration. Paul

Hi techie08. Yes, the Meru IDM solution is able to function as a radius server, both for captive portal and 802.1x authentication and accounting. It is able to authenticate against an internal database or alternatively via external directories such as AD/LDAP. Let me know if you have any further questions! Paul.

I would question the use of adaptive beam-forming in a high density environment. It makes sense for reaching a greater distance - as it was designed for, and works well in a point to point configuration or as a Muni-WIFI CPE - again as its original purpose. In a high density environment, with say 30 devices per classroom, the use of the more directional beams is reduced, leaving a more traditional radiation pattern from the AP. This means that in these more dense environments, the additional reach is either negated - or comes at a cost of more hidden nodes and reduction of throughput. As for replacement of Meru hardware, I am sure that all vendors have the ability to lay claim to replacing all other vendors' equipment. After all, the marketplace has been in an upgrade phase from 11abg to 11agbn for a number of years now. I could lay claim to having lost my confidence in all other Vendor technology also.

The care is taken by the system itself - as described by the videos. The beauty of the Meru solution is the ability to squeeze each channel for as much bandwidth as possible. With Meru, it is possible to provide 300Mbps datarate (using the AP300 3x3:2 MIMO AP) everywhere, on every channel without the issues associated with power and channel management. When you say the best option is adaptive RF, is this not part of the Meru Air Traffic Control? The ability to adjust power and CCA on a per packet, per client basis? Understanding the full RF environment, and acting accordingly - taking into consideration not just the clients associated to your AP, but all clients and AP's within an interference region (collision domain as per previous posts in the thread). Virtual Port on top of this, then enables the ability to take control back into the network from the client. As per the standard, the client chooses which BSSID he associates to, with Meru he is given a choice of 1, and this BSSID is then deployed onto an appropriate radio by the Meru Controller to ensure optimal performance not just for the client, but the entire network.

You can find the videos mentioned above here:Dr. Bharghavan Speaks

Hi all, I would have to argue that Meru does in fact mitigate Co-Channel interference, providing the ability for channel re-use and indeed a single channel across your entire campus. I have yet to see a deployment NOT take advantage of the Meru Single Channel Architecture. As for requiring a Pro to visit to get things working - I'd like to understand the justification for that comment! Operating on a single channel is the out of the box configuration, it requires NO intervention or tweaking from the customer or installer to work. It simplifies an installation as there is no longer ANY concern over channel planning, and power adaption (so therefore potentially impacting a functional area by adding an AP). Meru's CTO/Founder Dr. Bharghavan has a very interesting set of videos posted on Youtube under the topic 'Dr. Bharghavan Speaks'. Hopefully these should be able to answer some of your questions/concerns regarding the way Meru's architecture works. It will explain the core single channel architecture, which makes advanced capabilities such as true WLAN Virtualisation possible. If you have any doubts or questions, please don't hesitate to get in touch - I will be more than happy to discuss further.... Paul.

MRT, just spotted your post, not sure if this is an ongoing issue or not? As Impero is using a UDP broadcast for discovery, in a default configuration this will not be passed over the Meru WLAN. In order to resolve your issue, it is necessary to allow broadcast of the specific UDP port Impero is using... Unfortunately a quick Google search and browse through the Impero docs didn't reveal the port(s) they use. If you can determine which port(s) are in use, then under the main controller configuration, you can add specific allowed UDP broadcast ports. (I have emailed Impero quickly to ask for the detail) If this is still an ongoing issue, please feel free to PM me and I'll be happy to talk you through it!