Conference and event Wi-Fi is notoriously difficult to manage and run successfully. While deploying a wireless network at a large event with thousands of users can be challenging, there are many ways to increase the odds of a running a successful wireless network.
Meraki provided the Wi-Fi infrastructure that BT used at LeWeb in 2009 and 2010. The Wi-Fi at that event supported thousands of devices that pushed hundreds of gigabytes of data over the air. Loic LeMeur, LeWeb organizer, said, “People told us that the Wi-Fi network was one of the best they’d seen.” And here’s what @scobleizer said about it:
@scobleizer on Wi-Fi at LeWeb
We’ve learned a lot about running Wi-Fi networks at large events, such as LeWeb, so we’d like to share some of that with you. This blog post is the first in a three-part series:
Part 1 covers technical challenges, operational challenges, and design recommendations
Part 2 goes over network configuration recommendations
Part 3 gives tips for the event and shows some real-world results
Parts 2 and 3 will be posted during the next several weeks.
Part 1: Common challenges and design recommendations to address them
Why do so many events still suffer from poor Wi-Fi, even though Wi-Fi is a mature technology? There are many reasons. Often times a number of challenges conspire to “break the network.” The following are some of the more common challenges Meraki has observed.
The technical challenges are not trivial. Most conference attendees expect fast and reliable Wi-Fi wherever they may roam.
User density can be very high, with often hundreds or thousands of devices in a single conference room. However, there is only a finite amount of radio spectrum (channels) available to serve them.
The number and type of wireless devices is hard to predict. Users bring many wireless devices on site — Windows laptops, MacBooks, iPhones, iPads, and more — and expect them all to work.
The wireless devices all simultaneously attempt to associate when the users arrive on-site, or throughout certain points in the event.
As if the technical challenges weren’t enough, there are other challenges that the network administrator responsible for the wireless network must face.
It is very difficult to simulate the actual network load before the crowds arrive.
There is very little time to fix the network if it breaks during the event.
It may be difficult or expensive to get enough backhaul capacity.
Time on-site before the event begins may be very limited.
Taking the time to design the network properly can dramatically increase the odds of running a successful event. The following are recommendations we have found to be useful when deploying a large wireless network.
Allocate enough time for planning
The first step in planning a successful event is to allocate enough time. Ideally, you should begin planning 4-8 weeks ahead of the event. This ensures there is enough time to procure the necessary Wi-Fi equipment, switches, and backhaul circuits (often the longest lead-time item).
Calculate the expected number of clients that will be served
Use this number throughout the planning process. One approach is to use the expected number of attendees and assume a certain number (often 0.5-2) of devices per attendee.
Determine the number of access points (APs) needed
Although the APs do not have a hard client limit (they are limited by bandwidth, not number of clients), as a practical matter 50 client sessions is a safe limit and is convenient for planning. More clients can be supported depending on the bandwidth each requires, and at LeWeb we’ve had access points with over 100 clients. To avoid too many active clients, make sure to enable power reduction and band steering, and ensure there are enough APs installed in the environment to support the required load.
Event APs before deployment, courtesy of @maxwifievents
Calculate the backhaul required
Events are often plagued by limited backhaul. To calculate the backhaul requirement, multiply the bandwidth limit by the expected number of clients. For instance, if you expect 500 devices, and each device is limited to 100 kbps, then 50 Mbps of wired backhaul are required. While it is unlikely that all devices will use up to their full bandwidth limit, this conservative calculation will minimize the odds that the backhaul is insufficient. As backhaul can be very expensive, you will need to weigh this carefully.
Disable pre-existing APs
Before deploying the APs to be used at the event, make sure there are no APs already installed that may interfere with your network. Using a simple Wi-Fi planning tool, such as the Meraki Wi-Fi Stumbler, walk around the event area and search for APs. To the extent possible, disable those that you find so that they don’t interfere with your wireless installation.
Maximize the number of APs that are connected to the wired network
This allows an AP to use the full bandwidth of its wired connection, rather than having to go through a neighboring AP via a mesh link. If possible, Meraki recommends against using mesh at high-density events.
Use multi-radio APs
With multi-radio APs, the Meraki wireless network can make optimal decisions about channel assignment, band steering, and mesh networking. This maximizes throughput and minimizes channel interference for clients. Higher throughput 802.11n clients can operate on the 5 GHz band without being slowed down by older 802.11b/g clients, which remain on the 2.4 GHz band. Moreover, if mesh links are necessary, they can be provided on multiple radios, significantly improving the performance of the network across multiple mesh hops.
Map the APs
Name the APs and place them on the map appropriately. If there are multiple buildings or floors, it’s useful to combine the floor plans in one single image, so you can see all the APs from a single view, instead of loading separate images for each floor or location. When using mesh links, the network decides the best mesh route based partially on the locations of APs on the map. Even if you are not using mesh links, placing them on the map will help you if you need to troubleshoot issues during the event.
Ensure signal strength
The signal strength between a client and an AP should be at least 20 dB for optimal stability and performance. Consider anything less than 10 dB as unusable.
Budget for spare hardware
Stuff happens and sometimes things break. Spare hardware should be readily available in case of failures. For example, have an extra switch, APs, cables, and associated power supplies.
That’s it for part 1. Parts 2 and 3 will be posted over the next several weeks. If you have any experience running Wi-Fi at large events, please share it with us. What has worked for you, and what hasn’t worked?
Given the thousands of innovative education applications designed specifically for tablets as well as the integrated learning experience such apps can offer, it’s no wonder that iPads and other mobile devices are entering K-12 schools at an aggressive rate. In some cases the schools have rolled tablets out to every student, and in other cases students and teachers are bringing personal devices from home. Either way, schools are upgrading their wireless networks to accommodate the influx.
Red Lion Area School District in Red Lion, Pennsylvania and Rainbow District School Board in Northern Ontario, Canada both recently upgraded their networks to better support iPads and other mobile devices. The chief concerns, of course, are higher demands for bandwidth and the need for stricter network security.
Red Lion Area School District (RLASD) deployed over 120 Meraki 802.11n access points (APs) across 11 locations, with the largest number of APs at the 3000-student senior high school. “We needed a wireless solution with centralized management that was customizable,” said John Lenhart, Network Manager at RLASD. “We also needed something affordable but that still had enterprise-level features like active directory RADIUS authentication and the ability for a protected guest network.”
Lenhart explained that RLASD didn’t have the budget for a 1:1 initiative and therefore wanted to allow staff and students to bring in tablets and mobile devices from home—but still wanted to be able to protect the network with port filtering and AD authentication. Meraki’s cloud-managed solution enabled Lenhart to create separate SSIDs for district-issued devices vs. personal devices while also utilizing splash login pages, SSID schedules (only broadcasting the network during school hours), and NAC for added security.
Lenhart can also see what devices are authenticating and who is doing what. Macs, PCs, iPads, and iPhones have all joined the network with no problems, though Lenhart is keeping an eye on his bandwidth. The RLASD network is averaging nearly 200 GB/week. “We’re using Meraki Traffic Shaper to throttle down the student networks a little bit,” he said.
Figure 1: Red Lion Senior High
“The high school is really leaning on the wireless with a lot of devices.” –RLASD Network Manager John Lenhart
Rod MacLeod, Manager of Information Services at Rainbow District School Board, also praised Meraki’s Traffic Shaper as a way to prioritize bandwidth for learning activities at the district’s nine high schools. “Application shaping is the future of how things will work, rather than the old days when we tried to do everything by port,” he said.
Like Lenhart, MacLeod chose to upgrade his network to meet increased demand. “We had provided laptops for teachers, and more students were bringing personal laptops, iPhones, and iPads to school,” he said.
At the same time, he had concerns about his inability to monitor or limit the network traffic occurring on these portable devices. Rainbow’s deployment of 157 Meraki 802.11n access points across nine high schools provided greater capacity in conjunction with centralized management and more sophisticated insight and control.
To read more about Rainbow District School Board’s deployment, check out the case study. If you want to prepare your school for the iPad and its interactive learning applications, check out the Meraki iPad web page, or register for the iPad webinar.
We recently completed an anonymous survey of the end-user devices that connect to some of Meraki’s networks. The study reveals that iPads use significantly more Wi-Fi data than the average mobile device, and mobile platforms now outnumber desktop platforms in Wi-Fi networks. We also looked at the popularity of different device operating systems and the changes between 2010 and 2011.
The average iPad consumes over 400% more Wi-Fi data than the average Android, iPod, and iPhone.
Between 2010 and 2011, mobile platforms overtook desktop platforms in percentage of Wi-Fi devices.
iOS and Android together now account for 58% of Wi-Fi devices, compared to 33% just one year ago.
The iPhone is now the single most popular Wi-Fi device with 32% share.
Meraki Study Shows Mobile Platforms Overtake Desktop Platforms, Marked Rise of Android
To look at changes in end-user devices, we performed a comparative analysis between 2010 and 2011. The results show mobile platforms gained significant share over desktop platforms. Overall, iOS and Android together now account for 58% of Wi-Fi devices, compared to 33% just one year ago. Windows and Mac OS X together declined from 63% to 36%.
Our data shows iOS devices growing from 32% to 47%, and Android growing from 1% to 11%. In particular, the iPhone is now the most popular Wi-Fi device with 32% share. Desktop platforms declined, with Mac OS X going from 21% to 13%, and Windows shrinking from 42% to 23%.
Meraki’s Cloud Networking and Client Fingerprinting
Meraki’s unique cloud networking architecture enables in-depth analysis of user devices on our networks. During the past five years, we’ve deployed over 17,000 networks worldwide and connected more than 40 million unique end-user devices.
This data is made possible through our Client Fingerprinting technology. The technology identifies each device’s operating system, make, and model by analyzing network events and client information such as the NetBIOS name, MAC address, and other information. Once captured, this data is uploaded to the Cloud Controller. Due to our multi-tenant cloud architecture, insight into user devices is then made available to customers, and they can analyze network activity and troubleshoot client issues by accessing their network’s data from Meraki’s browser-based dashboard.
To collect these statistics, we anonymously surveyed over 100,000 randomly selected devices accessing general use, public, and educational Wi-Fi networks across the US. The survey looked at bandwidth usage and operating system popularity over selected periods in 2010 and 2011.
Internet connectivity for branch locations is often mission critical. For retail, hospitality, financial, and many other organizations, reliable internet connectivity ensures business continuity, uninterrupted financial transactions, and customer satisfaction. Branch connectivity is often established through leased private lines, such as multiprotocol label switching (MPLS) links.
The most attractive feature of MPLS is usually its reliability. Providers offer service agreements with uptime of 99.9% or higher. But this level of reliability comes at a high price, and rolling out MPLS to hundreds or thousands of branch locations quickly becomes prohibitively expensive. Fortunately, it’s now possible to aggregate multiple lower-cost access alternatives to achieve similar levels of reliability and performance. Meraki’s MX70 cloud-managed router makes this very simple.
Taking a hard look at connectivity costs
Using link failover and link aggregation, it’s now possible to take advantage of multiple internet access methods to increase the reliability of the branch network connection. The price of broadband access technologies such as DSL, cable, and even broadband fixed wireless has steadily declined over the past several years. By connecting more than one link at a time, the low price of these access technologies can be enjoyed without sacrificing reliability. For example, a branch location may have DSL and cable internet access available to it, but few other affordable options. In this case, each can be connected to the MX70’s WAN ports. To approximate the new level of reliability for two bonded links, use this equation:
1 – (1 – link 1 availability) x (1 – link 2 availability)
Figure 1 shows a cost comparison for two T1-MPLS links bonded together vs. bonding one cable and one DSL line together.
Figure 1: MPLS vs cable + DSL yearly connectivity costs for 20 branch locations
Figure 2 shows an MX70 router status page with two active WAN connections, as would be the case when bonding a cable line and a DSL line together.
Figure 2: MX router status with 2 active WAN links
The green indicators show that both WAN connections are live and active. If either link fails, traffic will be routed through the other WAN link, and network clients won’t see a disruption in their connectivity. When both links are active, their bandwidth can be aggregated and traffic will flow through both connections. The MX can also be configured to use only one primary WAN connection, using the other connection only in case the primary link fails. In both cases, the reliability of the branch connection is increased.
But this greater reliability isn’t the only benefit: since both WAN connections are active, the MX70 can aggregate their bandwidth, thus increasing the network performance. Internet traffic is spread among the uplinks in the proportion you specify in the dashboard, as shown in figure 3.
Figure 3: Uplink WAN aggregation
Tying it all together
Once branch locations have reliable and redundant internet connectivity, how can they connect to headquarters? The Meraki MX70 router has built-in site-to-site VPN capability that enables branch networks to automatically connect back to headquarters. For branches that have simple network requirements, the MX can connect the entire branch subnet to the site-to-site VPN. It’s as simple as selecting participation for the subnet, as shown in figure 4.
Figure 4: Participating in site-to-site VPN
Branches with VLANs can also be integrated into the site-to-site VPN. For each VLAN, simply choose if it participates in the site-to-site VPN, as shown in figure 4.
Figure 4: VLAN site-to-site VPN participation
For connecting multiple sites together, the MX70 provides a simple way to reduce your WAN costs, allowing you to eliminate expensive, leased private lines such as MPLS. Instead of buying one expensive MPLS line, take two lower cost links, aggregate them, and benefit from the built-in redundancy and cost savings. And once those branches are connected, monitoring and managing the entire network is extremely simple, because it’s done through Meraki’s web-based dashboard. The burden of remote site IT support is dramatically reduced, and network administration can be performed from a central location.
If you’d like to find out more about the MX series routers, don’t miss our next webinar on June 22nd at 11am Pacific time.
Apple’s iPad has continued to be in strong demand and this shows no sign of slowing down. Its popularity isn’t limited to the consumer market, and enterprises continue to adopt the device as a business tool. During our recent iPad webinar, our audience confirmed the iPad is continuing to gain traction in the enterprise.
While discussing second quarter results, Apple’s COO Tim Cook noted:
Employee demand for iPad in the corporate environment remains strong and CIOs continue to embrace iPad in an unprecedented rate. In just over a year since its debut, 75% of the Fortune 500 are testing or deploying iPad within their enterprises. Some recent examples of enterprises that are deploying iPad include FORTUNE 500 companies such as Xerox, AutoNation, Yum! Brands, ADP, Boston Scientific, Estée Lauder, Disney, Stryker, Prudential Financial, Rite Aid and USAA.
We asked our May 26th webinar audience about their own adoption and deployment plans for the iPad, and this is how they responded:
The results closely correlate with Tim Cook’s remarks. In our survey, 71% of organizations have either already deployed the iPad or are testing it in their networks. Another 26% are still evaluating and have not solidified their plans.
Even if you haven’t started officially deploying or supporting the iPad, perhaps you’d like to know how many users have brought their own iPads and access the wireless network. Using the Meraki dashboard, it’s really simple to see the iPads that have logged on and what kind of impact they have. If you’re looking for practical tips on integrating the iPad in your wireless network, check out our iPad whitepaper.