Another important requirement was to use low-cost resources for that.

Note: So far, this is my preparation for a solution that was not needed for the conference because we found a venue with wifi. So, expect this to not work out as intended the first time 😉 but it's a good source of inspiration to develop your own solution.

The "Wi-Fi on conferences" problem

Good presentations of the problem, and of solution alternatives:

Solution idea for a 100 people conference

The idea follows the same basic principles as all wifi setups for conference, with some simplifications because of the limited size:

  • DSL or cable line. A 15 MBit line should be sufficient for everybody's Internet use without restrictions, or anything from 6 MBit when having some rules and restrictions but being able to work without issues. So no special terrestrial radio broadband is needed, as done for large conference setups.
  • Router for Internet access. This is regularly already in place if the location has DSL or cable Internet. But to see if it is applicable: check its routing speed, NAT table capacity [source], and the DHCP server address capacity (if you don't use a normal computer as DHCP server). Example: I used a FritzBox 7050 as central router for a music festival office during 2 years, without capacity issues, with 40 concurrent users and ca. 300 devices in total. You can replace this router with one of those you use to provide wifi, if you need OpenWrt to provide more functionality in that router. Anyway, this central router should not provide any wifi if the signal can interfere with that in the conference room.
  • Five 100 Mbit switches. Provide five 16 port Ethernet LAN switches, to get at least the heavy users connected by wired LAN (expected here: 30 devices). By locating these next to each of the four wifi routers that provide the access points, it is simple to get electricity and a LAN cable to them – as the wifi routers need it too!
  • Five dual-band wifi routers. Provide enough of them for the others (expected here: 75 devices). Which means here, 5 dual-band routers. Normally one provides one access point per ca. 10 users for decent bandwidth in the 2.4 GHz band, or ca. 20-25 in the 5 GHz band (see below), so as the heavy users get cable connected and the wifi routers are dual-band ones here, we might easily get away with 15-20 per router. But that is untested yet – it also depends on how well the router itself can handle this. Here, I propose to use routers running OpenWrt, because I like free software and its flexibility, added options and long-term support. But it's not necessary in this scenario as the stock firmware will also provide all needed options. We will leave it simply to the users resp. their devices to connect to the 5 GHz band for a better wifi connection – only if the 2.4 GHz band is too crowded and the other too empty, we will have to tell users what to do to improve their connection. And if only by naming the 5 GHz network with an SSID that has a "-FAST" suffix.
  • Configure as access points. Make all devices Wireless Access Points, so all are using the DHCP server in the main DSL router. So, not configuring them as routers, and not using their own subnets, but all being in a same 192.168.0.0/16 network (for example).
  • Overlap-free channels. There are four in the 2.4 GHz band which you will use here: 1, 5, 9, 13 [see Wikipedia on 802.11 channels]. The 5 GHz band has many more. So probably place one router in every quarter of the audience, with both bands enabled, and an additional central one with just the 5 GHz band enabled. The interference of overlapping, plus the reduced power settings to compensate, will probably do more harm than waiving the 2.4 GHz band for that one router. This way, the fifth router is also a kind of backup device to replace one of the four others, if it breaks.
  • Rules. If you have a limited outbound Internet connection (< ~15 Mbps), provide some or all of the following rules:
    • No file sharing. This should be obvious on conferences regardless of the bandwidth. But you should know how to block bittorrent etc. traffic.
    • No video and audio streaming during conference sessions. Excludes the most bandwidth-hungry applications without taking much from users.
    • Heavy users, use cable. This includes users with low-latency requirements (Etherpad Lite, Google Docs) and the exceptional official livestream webcam of the conference. Compare also my post on Etherpad Lite bandwidth needs.
    • Use native Twitter clients. I did not test this yet, but it seems intuitively clear that desktop Twitter clients and mobile apps for that use less bandwidth than the official web-based version.
  • Proxy. If you have limited outbound Internet connection, but traffic at the conference revolves around a special site (like your organization's own site), it can make sense to add a transparent proxy.
  • Manage router connections by power level. The best trick so far to prevent a router's wifi cell to have bad performance because of too many users connecting there is this: monitor connection numbers during the conference sessions, and lower power levels of routers with too many connections, forcing some user devices to roam away to another router. See below for details.
  • Move routers around for sessions in smaller rooms. The five routers are sufficient for 100 people, but if your conference has not just the plenum sessions but sessions in smaller rooms as well, you either have to supply additional routers there or (cheaper, so better here) to just unplug one of the routers from the main room, put it in the small room, and later back. The main room obviously does not need it while some of its people are in a smaller room!

Technical background and alternatives

This sections explains the rationale behind the above solution, and also lists alternative ideas and why I consider them less adequate in this scenario.

What bandwidth is needed? Data from similar events include:

  • RIPE 59 tech conference, 300 attendees: "We peak at around 250 wireless clients online, and total 44 Mbit/s traffic." [source]

So in this case, for 100 attendees one would expect about 85 client devices and 14 Mbit/s peak traffic.

Getting users to the 5.2 GHz band as much as possible. This is way better, see these explanations. The 5.2 GHz equipment seems quite frequently used already. A report from PyCon: "The first year I ran the network (2006?), we had around 25% usage. In 2008 we had over 60% in 5.2GHz." [source]. So hopefully, just offering the 802.11a/n connection should result in enough users getting on that to free the 802.11b/g/n connections for those who have no alternative. If not, one might have to tell users how to explicitly select the 802.11a/n connection if they can.

Not supporting 802.11b. Configure the routers to not support 802.11b connections, because routers usually have way lower throughput in mixed mode that includes 802.11b, including the model recommended below [source]. The probably more important reason is that the 802.11b channels are 22 MHz wide. Which would leave us with 3 non-overlapping channels only. 802.11g connections allow 4 of these (1, 5, 9, 13) because their OFDM modulated channels are only 20 MHz wide, even when using 802.11g at 11 Mbps and lower transmission rates. For that, compare Wikipedia on 802.11 channels and its list of WLAN channels.

There should not be many 802.11b-only devices. Even phones from 2008 have 802.11b/g (like the HTC Magic). If too many people complain, allow 802.11b connections: there should not be so many that interference hinders throughput much.

Getting the heavy users connected by cable. This seems the best tech tip for conference setups [example]. For a smaller, more homegrown conference, it is sufficient to say that heavy users should connect by cable, it's not necessary to offer a cable connection at every seat, just at some. Like 20-30 for a 100 people tech conference audience?

Consumer enterprise access points? Also, you can of course buy Cisco Aironet 1200 hardware used. You get a AIR-AP1231G-E-K9 for 120 EUR at the moment, capable of just 802.11b/g and nearing its end of service life. No third-party firmware like OpenWrt is available for it either. In total, the vendor lock-in makes such enterprise hardware way less attractive than they seem at first.

Using WDS. OpenWrt has support for WDS. It is meant to enable seamless handover between access points, which probably means, so that the user does not notice a loss of connection. However, how big of a problem is it for users when not using WDS? How often do handovers happen anyway in a rather static conference setting (most people sitting and listening)?

Why to use the same SSID everywhere. This is because of the way roaming is implemented in wifi: "the client radio periodically scans all access points and reassociates with the access point having the strongest signal (if the current access point signal amplitude is below a specific threshold)." [source] But clients can only roam between access points with the same SSID.

So that is how setting things to the same ESSID makes roaming possible.

How to keep wireless access points from overload. Name all of them with the same SSID. Then, "during the meeting, […] monitor the distribution of clients amongst APs, and adjust power levels where needed to avoid overloading a single AP" [source]. That is a pretty nice trick: you don't kick individual clients off the network just to see them reconnect a few moments later. Instead, the clients at the edge will lose the connection when you lower the APs radio power, and automatically connect to another access point with the same SSID.

Using a wireless management system. It is mentioned that, for making a really professional large wifi deployment, one would employ a "wireless management system" [source]. The main features is controlling the radio power levels and channels to: detect and fix interference, and to detect and fix holes and overlaps in the coverage [source].

The non-proprietary wireless management solution is CAPWAP. (There are other proprietary technologies, partially at end-of-life: WLSELWAPP) Its open source implementation is called OpenCapwap (website, project site). It is possible (and seemingly the cleanest) to run OpenCapwap for configuring a set of same of different routers that run OpenWrt.

For the current requirements (100 users), CAPWAP was not employed: with just a handful of wireless access points, a simple static configuration is sufficient: no interference at all because of proper channel selection, and being able to use highest power levels then without causing interference. Here,  CAPWAP would be overkill, just increasing the complexity. But for high number of access points, CAPWAP seems great. But so far (2012-11), it is no solution to run out of the box: there seems to be no OpenCapwap package for OpenWrt, OpenCapwap itself is considered alpha, and some coding seems needed to send proper configuration commands to ones selected routers.

Automating configuration tasks. There are two semi-finished but maybe usable ways how to centrally control the configurations of a multitude of access points (as discussed here): cfengine and AirKey. But personally, once reaching a number of access points too much for manual configuration, I would move to fully automatic configuration – see on CAPWAP above.

Selecting a proper 802.11n router. The 802.11n wifi standard applied both to the 2.4 GHz and 5 GHz band [source]. So if a router supports 802.11n, it does not imply it is capable to use the 5 GHz band, which is better for conference settings. Make explicitly sure it is a dual-band router. It is if it also supports 802.11a, which is only on the 5 GHz band. But even then, there can be cases where the router supports 802.11n only on the 5 GHz band [example], so exclude that if you want the fast 802.11n everywhere.

Hardware selection

Hardware selection criteria

  • No integrated DSL modem needed. All the devices listed below have no integrated DSL modem, so the WAN port is essentially a network port (on a different VLAN for protection through routing) that is to be connected to a DSL modem. Connecting to another router with integrated DSL modem will also work. It is unclear to me so far if the DSL modem has to be one that allows to enter the access data into it, or if the OpenWRT router has that feature to control the modem (probably yes).
  • OpenWrt support wanted. There are other third-party firmwares as well, but OpenWrt seems to be the most advanced / stable / biggest one based on the number of its derivatives [source].

Hardware selection list

By adequacy. After looking through more or less all brandname devices supported by OpenWrt as of 2012-11.

D-Link DIR-825. My favorite so far! Its B1 and B2 hardware revisions are supported by OpenWrt [source] and since the A1 revision is not sold new any more [source, in the customer review by Steve B] it should be simple to get the right version by buying new. However there is now also a C1 revision, and it is unclear to me so far if OpenWrt supports it since it only supplies the openwrt-ar71xx-generic-dir-825-b1-* firmware files. However, the DD-WRT project explicitly supports the C1 version now [source, firmwares here] so there is an alternative what could be installed on it.

Installing OpenWrt does not need a serial console, which is nice [source]. The device is available also new in larger quantities and short time from Amazon. Difference to the Netgear WNDR3700 / WNDR3800 might be subtle / subjective. I chose this one because of the better customer reviews on Amazon. And because some people with wifi-for-big-conferences experience consider some other inexpensive D-Link devices solid and adequate for that setting [source]. Which does not say much about this device of course. A very detailed test and review is found at smallnetbuilder.com and also at cnet.com.

Netgear WNDR3800. A detailed review is available here. Use with OpenWrt and specs are pretty much the same as with the Netgear 3700, see below.

Netgear WNDR3700 v1 / v2. These are true dual-band routers, providing 802.11a/n on 5 GHz and and 802.11b/g/n on 2.4 GHz. Well supported by OpenWRT. Available in sufficient quantities on eBay in Europe (about 75 EUR per piece on eBay as buy-now, from 77 EUR in normal shops). But one has to make sure to not get a WNDR3700 V3 model, as this is not supported at all by OpenWRT. Installation is possible without a serial console [source]. A detailed review is available here, including customer opinions which are quite mixed. The WNDR3700 v2 version has actually worse reach in the 5 GHz band due to antenna changes [source], but you might decide that this does not matter in a one-continuous-room conference setup.

Linksys E3200. Also a true 2.4 GHz and 5 GHz dual-band router. But itneeds the OpenWrt trunk (unreleased) version, and for installation also the serial console [source]. Also, much fewer devices are available on eBay (mostly oly auctions, then 40-50 EUR). Best source is 50 EUR new from here.

Linksys WAP4410N. Nice very modern one, OpenWRT supported, but quite expensive (150 EUR).

Linksys WRT160NL. More modern than the WRT54GL series routers, supporting 802.11n. However only on the 2.4GHz band, which makes them pretty useless for our purposes here of avoiding the 2.4 GHz band as much as possible. Available in sufficient numbers on European used item market, 50-75 EUR as buy-now on eBay.

Linksys WRT54GL. Well supported by OpenWrt, as they are the continuation of the original series that inspired OpwnWrt. Available in greater numbers for "buy now" on eBay. Available in sufficient numbers on European used item market. But only supporting up to 802.11g, and not the 5 GHz band at all (so pretty useless for our purposes).

2 thoughts on “How to provide Wi-Fi Internet access for a 100 people conference?

  1. Amazing writeup! I’m on a team organizing a yearly conference – also in Germany – at a location with horrible wifi for the organizers hopefully I’ll get them to upgrade after filtering out a solution for them so at least the team has something stable. Thank you!

  2. Nice post. i have this problema in all conferente. I will try follow your tips.

Leave a reply

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>