12 Ways to Optimize Your Event Wi-Fi Deployment

Part 2: Network configuration recommendations

The previous post in this 3-part series covered technical challenges, operational challenges, and design recommendations. This part will cover network configuration recommendations. Part 3 covers tips for the event and real-world results.

These are more practical tips for the network, this time focusing on specific network configurations and settings we’ve found to be helpful in large event scenarios.

  1. Enable bandwidth limits
  2. This is probably the most important single consideration. If bandwidth limits are not enabled, a small number of clients can quickly saturate a channel. For most events, a per-client limit of 100-200 kbit/s is appropriate, and this will provide a snappy web browsing experience, reasonably fast email, and usable video. Higher limits (1-2 Mbit/s) will, of course, enable higher-bandwidth applications. However, this will require that there is enough local and wide area bandwidth available to support all users at this limit.

    One simple and effective strategy is to start with low limits and, if no problems are encountered, then gradually increase the limit. It’s very easy to change the limit using the dashboard:

    Figure 1: Per-client bandwidth limit

    Make sure to disable SpeedBurst. SpeedBurst allows users to temporarily exceed the bandwidth limit for short periods while still keeping them under the bandwidth limit over time. For large events with many users, this is undesirable.

  3. Shape application traffic
  4. Consider blocking applications that might be considered abusive, such as file-sharing software. Also consider rate-limiting applications that may consume large amounts of bandwidth, or those that do so automatically or perhaps with little notice from the user, such as automatic backup software. For example, @cramforce recently noted: “One person at JSConf uploaded 9.6 GB in the first 30 minutes of the conference.” — Ouch! Using Meraki’s layer 7 application traffic shaping, you don’t have to worry about protocols, ports, or IP addresses. That goes for the end-user and the application as well.

    Figure 2: Traffic shaping online backup applications

  5. Enable NAT
  6. Centralized DHCP servers often fail or become slow when hundreds or thousands of clients request an IP address in a short time. Imagine all those conference attendees attempting to join the network at the same time. Painful! We strongly recommend enabling Meraki NAT, which spreads the DHCP load among all the APs.

  7. Limit splash page size
  8. We recommend limiting the size of the splash page, if you use one. This reduces congestion during a time at which many clients are accessing the network for the first time. 10-50 KB is a reasonable target.

  9. Enable auto channel assignment
  10. Auto channel assignment allows the Meraki Cloud Controller to assign channels to Meraki APs in the network using RF information that the APs constantly send up to the Cloud Controller. Unlike traditional wireless solutions, in which channel assignment decisions are made by each AP in a localized manner, the Meraki Cloud Controller ensures that channel assignments make sense locally as well as globally, relative to the rest of the network.

  11. Enable channel spreading
  12. Channel spreading enables Meraki APs in the same vicinity (e.g. in the same auditorium) to broadcast on different channels so that channel utilization on each channel is minimized. This maximizes throughput and minimizes interference in the network. The Meraki Cloud Controller automatically assigns channels to achieve channel spreading.

  13. Enable band steering
  14. Band steering forces 5 GHz-capable wireless devices (e.g. most 802.11n clients) to migrate away from the 2.4 GHz band. This opens up radio spectrum for legacy wireless devices (e.g. 802.11b/g clients). This is highly beneficial since there are many more 5 GHz channels than 2.4 GHz channels.

  15. Reduce AP transmit power
  16. Reduced transmit power reduces the range of the AP, such that a user associates only with the nearest AP in a room containing multiple APs. This helps distribute the users across the APs deployed in a single physical space.

  17. Set 5 GHz channel width to 20 MHz instead of 40 MHz
  18. Normally, the 5 GHz band is used to support higher-bandwidth applications and users. In this case, this configuration allows for a greater number of individual channels, which is usually desired in a high-density setup. This change is only applied to 5 GHz radios since 2.4 GHz radios already use 20 MHz channels by default.

  19. Avoid interference
  20. The Meraki Cloud Controller will automatically select the right channels to use for each AP based on channel spreading, interference, and other factors. You can use the channel planning report to view how the channels are occupied.

    Figure 3: Channel planning report

  21. Use static IP addresses on APs
  22. This setting reduces the APs’ dependency on an upstream DHCP server.

  23. Disable legacy 802.11b rates
  24. Slow rates (e.g. 1 or 2 Mbit/s) can enable a small number of clients to consume a disproportionate amount of “airtime.”

Proactively configuring these settings will go a long way towards ensuring your wireless network is prepared to handle the most demanding users and applications. Then, during the event, time can be spent troubleshooting specific issues as they arise, instead of trying to find the optimal network configuration settings on-the-fly. Don’t miss part 3 of this series – tips for the event and real-world results.