Skyrove recently provided Wi-Fi access at G South Africa, Google’s first big conference in Cape Town.
Google’s requirement was broadband speed internet access for 500 delegates across 2 conference rooms. The first day of the conference was aimed at software developers and CS students (Android, AppEngine, Maps, GWT etc) while Day 2 was for Business & Marketing folks.
Besides for watching our network traffic and connections closely, all of our technicians were also monitoring, and replying to, Twitter for comments about the Wi-Fi (by searching Twitter for “#gsouthafrica WiFi”)
There were 48 positive tweets & retweets about the Wi-Fi and 8 negative ones by 3 different people. Not a great ratio, but then you’d find that, like working sound and lighting, people expect Wi-Fi to “just work” and are seldom amazed by it.
So we were glad to see some really positive ones:
Not everything was plain sailing though, and on the first day we were scurrying around moving load from one backhaul connection to another. After fixing some backhaul problems, on Day 2 we had 550 connected devices, with data usage double what it was on Day 1 and not a single negative tweet.
Conference & Event Wi-Fi is tough and many network operators underestimate what will be required. In 2008 Wi-Fi at Le Web failed spectacularly, despite Swisscom charging 100,000 Euros. (See Michael Arrington’s TechCrunch post on the Wi-Fi failure)
1. Do: Communicate with speakers and delegates
Find out as much as you can about the speakers’ presentations before they go on stage. It’s becoming more and more common for speakers to stream content directly from YouTube or do live demos of Web 2.0 applications.
Also make sure you remain calm and courteous when there are problems. I made the mistake of trying to explain the importance of the integrity of the network to speakers who just urgently needed speedy connectivity. Tell them firstly that you will fix their problems. Then try to ascertain quickly what exactly the problem is and whether it’s isolated. (Remember, someone under pressure having a problem will almost always tell you that everyone is having a problem… you need to ascertain this for yourself)
Also make sure delegates get any passwords as part of their handout. Best way is an insert into nametags if possible.
2. Do: Dedicated Access for speakers on a physically separate network.
We had two Speaker Wi-Fi networks, one virtual and one on its own ADSL circuit. On Day One we had problems with our ADSL modems struggling under the load of 450 people which adversely affected the speaker virtual network.
3. Don’t: Use Splash / Login Pages
We had a simple Splash Page to welcome people to the Wi-Fi network and explain that some services were shaped and what they should do if they needed help. This was simply a barrier and in many cases people wouldn’t see the splash page if they tried to access the internet without first starting up a browser.
4. Do: Use the right equipment
We used two types of equipment, Meraki MR14 ($800) 802.11n routers which could cater for a 100+ users each and Ubiquiti Rocket M (~$250) devices as our backup solution. The Meraki routers worked beautifully, and we only needed to use a single Rocket M device to get more coverage. Meraki enabled us to have multiple SSIDs, each with separate speed limits and shaping policies. However, we couldn’t limit the upstream bandwidth with the Merakis, which meant the buffers on our modems overflowed and had to be frequently reset until we replaced them with better modems.
The really useful feature of Meraki was that we could clearly see which devices, and which applications, were using the most bandwidth. All of this was through a user-friendly web interface and changes could be made rapidly through this without remotely logging into the devices individually.
We also added some features to the Rocket M firmware using the AirOS SDK that enabled us to get more insights about user behaviour, but not nearly as much as Meraki could give us out of the box.
The Meraki devices also did Channel Spreading and the Cloud Controller would reduce radio power on APs they caused interference with each other. Combined with MIMO, beamforming and spatial multiplexing meant that we never had problems with people’s devices connecting to the Wi-Fi network.
5. Do: Proper Backhaul
We spent a lot of time and money planning the the Wi-Fi network to ensure we could have hundreds of devices online simultaneously. But whereas we had spent about $8,000 on Wi-Fi equipment, we only spent $150 on ADSL modems. They were cheap & nasty and ultimately fell over.
The biggest challenge with conference Wi-Fi is proper backhaul. We’ve had conferences where our upstream provider would change between satellite & fibre and back again without any warning. We’d suddenly get major latencies and, having hundreds of people online already, it’s very difficult to troubleshoot as you can’t bring down the entire network for a test.
It’s hard to convey the difficulty and expense of this to event organisers. For many people, internet is a utility like electricity or water and it’s expected to just work. You also have very little possibility of fixing a backhaul problem on the day of the conference, so it’s crucial to plan this weeks in advance. And always have a fallback solution that can cater for the most critical needs.
6. Don’t: Underestimate Costs
There’s a reluctance to spend money on conference Wi-Fi because of it’s “temporary” nature. But let me put it this way: It’s tougher to set up a network for 500 conference attendees than it is to set up a network for a company with 500 employees. With the latter, you can set clear and strict policies and often control the network down to the device level. You typically have days to build a company network, as opposed to hours.
And you also don’t risk the company’s employees tweeting every time Facebook takes too long to load, which has a very hard cost to your brand, especially at popular conferences.
7. Do: Test, Test, Test
t’s common to do a bunch of quick Wi-Fi signal & throughput tests. But what’s really necessary is to test every type of application that may be used on the day. Set up a few computers to run BitTorrents and large file-downloads and see if the net is still usable.
These are simple tests and won’t give you the most comprehensive results, but it will help you eliminate some basic problems.
8. Do: Prepare!
Before committing to doing the conference, do a proper site survey of the location. Are there enough powerpoints? Where can you terminate backhaul? Is there a location where your engineers can work from and observe what is happening on stage as well as the network? Is the ADSL Exchange in the area known to give problems? Can you use 3G as a backup?
9. Don’t: EVER install a solution for a venue and say you can remotely support it.
Even though this is theoretically possible, in reality, you simply won’t know what the speakers or delegates might throw at you. We made this mistake once. Besides for things going wrong while we weren’t there, we also gave up an opportunity to charge the conference organisers for our time, who were willing to pay.
10. Don’t: Undercharge!
I don’t know of any Audio-Visual companies who do free AV (sound, screens, lighting) or any caterers who give free food for conferences. Yet, because free Wi-Fi has become so pervasive at coffeeshops, there seems to be the perception that Wi-Fi is something cheap and easy. It’s not. If you don’t charge, you are less likely to have your best engineers to work on it and you are less likely to buy the equipment that you should be using.
Compare your rates with other conference costs (caterers, AV, venue) and look at the expertise required. Charging 100,000 EUR for 1,700 people is not completely out of whack. You may not be able to charge as much as you could for setting up a corporate network, but don’t undercharge either.
There are often sponsorship opportunities and exhibition space available, usually at a 2:1 ratio, which is good, but if you go in with cheap Wi-Fi that doesn’t work, you will only damage your brand.