The growing number of wireless devices and wireless applications are the driving force behind the most significant trend seen in the market – the fundamental failure of legacy microcell wireless networks to handle high density environments, what is referred to as the “WiFi meltdown”.
What is considered a high density environment? As employees, customers, and hotel guests introduce two to three wireless devices each at any given location, the ability to support 80, 84 or anything less than 100 wireless devices is simply not enough.
Meru defines high density as an environment which supports over 500 wireless devices – like a convention centre, campus auditorium or hotel lobby. A meltdown happens when the wireless LAN fails to support hundreds of wireless devices at a time.
The world took notice at the WWDC Conference in San Francisco in June 2010, when Steve Jobs attempted to launch the demo announcing their widely anticipated iPhone 4, but the demo derailed by overloaded airways as over 1,100 attendees attempt to go online at the same time.
In addition, the Mobile World Congress (MWEC) 2011 once again kicked off with absolutely no WiFi.
Why does a WiFi meltdown happen?
The problem here is microscell. This inherent desire of enterprise WiFi microcell-based equipment to avoid interference and operate as if it doesn’t exist, in particular the ones that attempt to adapt to changing RF conditions, causes high susceptibility to RF interference and noise and creates a network with a single point of failure at the users’ connection (that is from the AP to the client device) particularly in high user density situations.
When WiFi was initially adopted by the enterprise, it was deployed primarily as a spot network – conference room here and there, the commons areas, and so on – basically a network of convenience. What they never envisioned was today’s explosion of devices coupled with pervasive coverage needs of a primary access network and its implications on the underlying deployment architecture.
Simply adapting radio signals doesn’t work in these situations. Continuously avoiding other APs, at some point, breaks down and significantly affects clients attached to the network.
Adapting is an attempt to compensate for poor architectural design that forces the IT staff into labor intensive designs and increases the technical requirements on support staff in terms of what training is required to run the network.
Unfortunately, as user growth continues to outpace all expectations, adapting falls far short of solving the problem.
How to avoid a WiFi meltdown
Meru’s virtualised architecture is purpose-built to support the proliferation of wireless devices and applications and more critically, avoid a WiFi meltdown, as it demonstrated with its WLAN 500, where more than 500 iPhones, iPads and other wireless devices were operated in a 500 square foot area – streaming voice, video and data concurrently.
Meru’s architecture, based on virtualisation, is designed from the ground up to account for interference and work with it, for two simple objectives:
* Make WiFi support enterprise mobility – whether it’s small enterprises or large conventions.
* As the RF gets more complicated and users increase, place the burden of managing RF and everything going on over to the system and allow users to do what they do best – manage networks and IT systems.