High-Density Conference WiFi in the Real World – My experiences & thoughts.

So it’s been a little while since I wrote anything on my blog, and recently a lot of my time of late has been consumed with designing and deploying some high density wireless networks for major events – I’m on about 1500-2000 tech nerds with 2/3 devices each sat in a block of seats in an auditorium generating 200-300 Mbit/s of traffic!

One area of my work that I frequently discuss with colleagues and also with other engineers that I meet is the approach I take and what settings I use in our controllers so I thought I might document my “typical” setup here for anybody interested.   I would also welcome discussion / input on this from anybody out there that also works in these sorts of environments – what do you find works, how do your results compare to mine etc.  Whilst the focus of this post is obviously on how I configure our Cisco gear to work the same principals should apply to any of the major enterprise vendors offerings.   My starting points for these settings were based on what I found works in the real world and also from the Cisco / Aruba HD WLAN deployment guides (the Aruba one is easily one of the best out there and a highly recommended read for any WiFi engineer undertaking a high-density deployment).

System Notes:
Cisco WLC’s running Code.
Cisco 3602 Series AP’s.
CleanAir enabled, EDRRM enabled and set to high thresholds.
AP’s typically mounted in seating / low level.
Patch antennas where possible / appropriate, but I often do a lot with just internal omnis as time constraints of rigging the system are often against me.
Cells sized to try and keep ~50-70 clients per radio.
Use some AP’s as 5GHz only cells for extra capacity in that band.
I  install a couple of well placed monitor mode AP – I often leave one in SE-Connect mode.
Willingness to tell all legacy clients to get stuffed! It’s 2012, go get an 11n capable device!

Rough Design Goals:
I aim for uniform -64dBM coverage at 5Ghz, target TX power levels on the AP’s is normally around 9dBM to achieve this.   Cell to cell isolation should be at least 15dBM and in an ideal world 40MHz of spacing between adjacent cells at 5GHz to reduce CCI/AOCI as far as possible.

2.4GHz coverage is always fun, isolating cells from each other is a big challenge.  Under seat mounting of AP’s and careful use of sector antennas helps here a lot, less is defiantly more in this area, use no more TX power from the AP than necessary.

Design with client devices in mind, typically for me that means a pile of iPhones and Mac laptops at the type of shows I work on – find the specs, get the devices and work out what they are capable of!

2.4GHz WLAN RF Profile:
Rates – 18Mbit/s Supported, 24Mbit/s Mandatory, Everything else disabled.
RRM TPC – Max TX Power 11dBm, Min TX Power 3dBm, Power Thresholds -80dBm.
Coverage Hole Detection – Data RSSI -70, everything else defaults.
HD Settings – Multicast rate 24Mbit/s, client trap threshold 50.
Load Balancing – Window size 8, denial 2.
Band Select – No probe responses, 4 cycles, everything else default.

5GHz WLAN RF Profile:
Rates – 18Mbit/s Supported, 24Mbit/s Mandatory, Everything else disabled.
RRM TPC – Max TX Power 15dBm, Min TX Power 6dBm, Power Thresholds -71dBm.
Coverage Hole Detection – Data RSSI -70, everything else defaults.
HD Settings – Multicast rate 24Mbit/s, client trap threshold 75.
Load Balancing – Window size 8, denial 2.

Misc Settings:
I use a couple of ACL’s to clean up junk traffic on the network.
Peer-to-Peer blocking is enabled on WLAN profile.
Band Select & Load Balancing enabled on WLAN profile.
Might use VLAN pooling if large enough install.
IPv6 Disabled (sucky I know).
Global Multicast enabled + Multicast VLAN set on WLAN profile.

QoS / Rate Limiting:
I find this to be a difficult area when it comes to considering what to do.  I generally don’t like the idea of outright brick wall style limits, though I do think that application awareness in the wifi kit can be very useful to drop the priority of specific bandwidth hungry web apps such as streaming media sites and other services like DropBox.  Airtime Fairness systems are a must here too, but typically all the clients will be using high data rates and there should hopefully be minimal legacy clients to deal with.

Results / Observations:
I typically find that in a ~1,500 seat auditorium with a planned take rate of more or less 100% and where every person will likely have 2 connected devices I will use 12-15 AP’s if under seat mounting and might add a few extra for 5GHz filler – I also tend to bolster capacity around doorways / entrances to the seating area foyers etc as they can get very busy pre-show.

2.4GHz suffers heavily, even with the best will in the world, careful design of cells and use of many sector antennas I will generally find that after about 1,200 connected devices channel utilisation just becomes too high.   The network generally doesn’t outright fail but will become more or less useless for anything other than tweeting / very light browsing.   I might expect to shift around ~30Mbit/s of traffic on the 2.4GHz side of the WLAN in that area depending on the show.  Typical retry rates on the network at 2.4GHz sit at around 18-22% which is high, but not alarmingly high for the environment.

Generally all clients have an excellent SNR and get connected without a fuss even despite of my very aggressive legacy rate settings, and the load balancing settings I use normally results in a good balance of clients on the access points.

5GHz is now becoming more heavily loaded, in fact I have just done my first event where I have had a public network with a greater proportion of clients connected via 5GHz than 2.4GHz – likely down to a good number of the punters having a high end smartphone with a 5GHz radio inside it.

Main Auditorium WLC - Client Protocol Distribution
WLC – Client Protocol Distribution

In the 5GHz band channel utilisation tends to sit at 30-40% and will spike up to 70%, careful channel planning can help but DFS requirements in Europe (we only have 4 non DFS channels) can make that quite hard to statically assign channels with the density of collocated AP’s in a typical auditorium.  Retry rates here are always pretty low even if the network is under load, typically 10-12% creeping up to 15-20% on an overloaded cell.

Actually, whilst we are on the subject of DFS recently I have found it to be a right pain in the arse.  Recently in a venue in France during the build we observed absolutely no DFS events, however as we found the venue beginning to fill we were seeing what I can only assume to be a lot of false positive DFS events, likely caused by spurious radio energy from the very busy network as the client count began to rise, the result – lots of AP’s that had previously had *excellent* isolation from each other ended up sharing the same air spare in close proximity – network performance was certainly impacted by this although user experience remained acceptable.   It seems (and I could be wrong on this) that I can’t make a Cisco system ignore DFS events if I am sure they are false positives, and whilst I guess that is the required way to operate I do know of at least one vendor who provide this configuration option.

Network stats from a major tech conference over a day, traffic graph is data over the WiFi network only.

So there we have it, I’m sure that there are loads of things I could talk about in this area but those above are the key points for me.   At the end of the day I bend the rules and don’t always do things according to a vendors best practices or guidelines or even what other people tell me simply wont work, but then I have the advantage of not working in a corporate environment where I am free to try slightly outrageous settings and push the limits of what people may have tested in a lab or on a workbench.

I hope anybody that reads this finds it useful or maybe even possibly interesting and I welcome any comments, feedback or suggestions!  🙂

One thought on “High-Density Conference WiFi in the Real World – My experiences & thoughts.”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.